Anyone have any thoughts on the best way to install my own policy files on a few machines.
I have to go out and find a way to install a policy file, install my own file_context files, and then compile and load the new custom policy and fc files.
These systems would be running standard FC3 with the targetted policy, but without the targetted sources.
I would like to set them all up so that they then have my own version of the strict policy, without having the source files installed.
Is rpm the best way to attack this or are there better options out there? As I see it I would have to include the policy-strict-<version>.rpm as well as setools-<version>.rpm within my own rpm file in order to load everything necessary to load the policy and relabel the filesystem.
On Wed, 2005-06-15 at 14:27 -0400, Security News wrote:
Anyone have any thoughts on the best way to install my own policy files on a few machines.
I have to go out and find a way to install a policy file, install my own file_context files, and then compile and load the new custom policy and fc files.
These systems would be running standard FC3 with the targetted policy, but without the targetted sources.
I would like to set them all up so that they then have my own version of the strict policy, without having the source files installed.
Is rpm the best way to attack this or are there better options out there? As I see it I would have to include the policy-strict-<version>.rpm as well as setools-<version>.rpm within my own rpm file in order to load everything necessary to load the policy and relabel the filesystem.
setools isn't needed for SELinux operation; they are purely optional tools for policy analysis and management.
It sounds like you want to perform a wholesale replacement of the policy on these systems. That should be feasible without requiring policy sources on the end systems (in the future, it will be possible to also distribute binary policy modules that can be linked into the base policy on the end systems without requiring sources on the end systems, but that support won't be available until FC5).
I'm not sure why you need anything other than a selinux-policy-strict package (which contains the binary policy file, the file_contexts configuration, and other policy-related config files) with a modified post scriptlet in the spec file to perform the conversion (e.g. switch to permissive mode, change /etc/selinux/config, load new policy, relabel filesystems, reboot). Naturally, the devil is in the details; you'll want to try it on a non-production system first.
Sorry, in the first post I meant to say that I wanted to install the policycoreutils<version>.rpm (the devil really is in the details.)
--the reason for needing this rpm is that I am hoping to be able to install a custom policy and file-labelling without installing the source configuration files. This is just so that even a root user could be kept from editing my policy.conf files. I need the coreutils b/c if the source config files are not going to be present then neither is the Makefile, so I would need to use "fixfiles relabel" and "load_policy".
Unless, there is a better way to load and relabel when not installing the config source files.
I am hoping to have this installation be performed by someone else somewhere else, and to make the installation as mindless as possible for them.
Thanks,
-Dan
On 6/15/05, Stephen Smalley sds@tycho.nsa.gov wrote:
On Wed, 2005-06-15 at 14:27 -0400, Security News wrote:
Anyone have any thoughts on the best way to install my own policy files on a few machines.
I have to go out and find a way to install a policy file, install my own file_context files, and then compile and load the new custom policy and fc files.
These systems would be running standard FC3 with the targetted policy, but without the targetted sources.
I would like to set them all up so that they then have my own version of the strict policy, without having the source files installed.
Is rpm the best way to attack this or are there better options out there? As I see it I would have to include the policy-strict-<version>.rpm as well as setools-<version>.rpm within my own rpm file in order to load everything necessary to load the policy and relabel the filesystem.
setools isn't needed for SELinux operation; they are purely optional tools for policy analysis and management.
It sounds like you want to perform a wholesale replacement of the policy on these systems. That should be feasible without requiring policy sources on the end systems (in the future, it will be possible to also distribute binary policy modules that can be linked into the base policy on the end systems without requiring sources on the end systems, but that support won't be available until FC5).
I'm not sure why you need anything other than a selinux-policy-strict package (which contains the binary policy file, the file_contexts configuration, and other policy-related config files) with a modified post scriptlet in the spec file to perform the conversion (e.g. switch to permissive mode, change /etc/selinux/config, load new policy, relabel filesystems, reboot). Naturally, the devil is in the details; you'll want to try it on a non-production system first.
-- Stephen Smalley National Security Agency
On Wed, 2005-06-15 at 14:53 -0400, Security News wrote:
Sorry, in the first post I meant to say that I wanted to install the policycoreutils<version>.rpm (the devil really is in the details.)
--the reason for needing this rpm is that I am hoping to be able to install a custom policy and file-labelling without installing the source configuration files. This is just so that even a root user could be kept from editing my policy.conf files. I need the coreutils b/c if the source config files are not going to be present then neither is the Makefile, so I would need to use "fixfiles relabel" and "load_policy".
Unless, there is a better way to load and relabel when not installing the config source files.
I am hoping to have this installation be performed by someone else somewhere else, and to make the installation as mindless as possible for them.
policycoreutils is always needed for SELinux, so it should already be installed on the base FC3 systems running targeted policy. You would only need to install a different version of it if your strict policy relies on a newer base version of policycoreutils than the stock FC3 one (at which point you may want to check whether you also require a newer libsepol and libselinux as well).
Stephen Smalley wrote:
On Wed, 2005-06-15 at 14:53 -0400, Security News wrote:
Sorry, in the first post I meant to say that I wanted to install the policycoreutils<version>.rpm (the devil really is in the details.)
--the reason for needing this rpm is that I am hoping to be able to install a custom policy and file-labelling without installing the source configuration files. This is just so that even a root user could be kept from editing my policy.conf files. I need the coreutils b/c if the source config files are not going to be present then neither is the Makefile, so I would need to use "fixfiles relabel" and "load_policy".
Unless, there is a better way to load and relabel when not installing the config source files.
I am hoping to have this installation be performed by someone else somewhere else, and to make the installation as mindless as possible for them.
policycoreutils is always needed for SELinux, so it should already be installed on the base FC3 systems running targeted policy. You would only need to install a different version of it if your strict policy relies on a newer base version of policycoreutils than the stock FC3 one (at which point you may want to check whether you also require a newer libsepol and libselinux as well).
Also fixfiles/restorecon/setfiles do not require policy sources to be installed. They use the file_context files in
/etc/selinux/TYPE/contexts/files/ directory.
Dan
On Wed, 2005-06-15 at 14:41 -0400, Stephen Smalley wrote:
I'm not sure why you need anything other than a selinux-policy-strict package (which contains the binary policy file, the file_contexts configuration, and other policy-related config files) with a modified post scriptlet in the spec file to perform the conversion (e.g. switch to permissive mode, change /etc/selinux/config, load new policy, relabel filesystems, reboot). Naturally, the devil is in the details; you'll want to try it on a non-production system first.
BTW, if it is a custom policy (not just the stock Fedora strict policy), then you should give it another name other than strict and put it under its own subtree of /etc/selinux to avoid conflicts (and potential replacement by the Fedora strict policy upon subsequent updates).
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Security News -
Stephen Smalley