Jeff Johnson wrote:
Daniel J Walsh wrote:
As I have been trying to build a new policy we kept on coming up with problems in replacing the current policy file with either strict or targeted policy. In the next version of Fedora Core we will be shipping a targeted policy on the iso images. We will continue to make the strict policy available separately. The problem comes in that these policy files conflict and we continued to work on how we could allow them both to be installed and have the user fairly easily switch between policies. With this new design, I could envision other policies being added in the future and test machines able to switch between the policies.
1. We are breaking the policy file out into two separate policy packages
selinux-policy-strict (-source also)
- Containing pretty much the current policy
selinux-policy-targeted (-source also)
- Containing a policy where most processed run in unconfined_t and only specific services run under a different security context.
2. Both packages obsolete the current policy rpm.
3. We want both policy files to be installable and not conflict with each other.
Hmmm, how is rpm to find out which file_contexts is to be used? Or is targeted policy a strict ;-) subset
of strict policy?
libselinux is converted to use the correct one. selinux_policypath is set the the dirctory where the policy is installed during library initialization.
So files contexts would be in ${selinux_policypath}/contexts/file_contexts please excuse the pseudo code.
4. Policy files will be installed in the /etc/selinux/(strict|targeted) directory.
Under this tree there will be at least three additional directiories
policy/ Containing the compiled policy file
contexts/
Containing all the contexts files
file_contexts, default_contexts, default_type
users/
Containing user specific default context files. root in particular.
src/ Containing the policy src directory.
5. Tools and libraries (fixfiles, libselinux, init, and setools) will be modified to use the /etc/sysconfig/selinux file to determine which policy to currently use on the system and where the policy files are located.
6. If during the install /etc/sysconfig/selinux does not exist or does not contain an entry for the type of policy, the first one installed will set the context to itself.
How much legacy compatibility is desired? I sure hope you say "None." ;-)
We are looking for a clean break. Since we have a small installed base, this should be possible. :^)
cat /etc/sysconfig/selinux # # Change the following line to enforcing, permissive or disabled. # On the next boot the machine will come up in one the selected mode # SELINUX=enforcing # # Select the type of policy that you are running current values are # strict and targeted # SELINUXTYPE=strict
So if nothing is in the /etc/sysconfig/selinux file and you install strict, strict will be added
to config file. If there is an entry then it will be left there.
This will allow the installation of both the Strict and Targeted policy and the user can change the choice via this file and can then relabel
7. We will not use symbolic links. Use of symbolic links complicates policy and requires a user to modify them if he wanted to change the security context that he wants to run as. Also you end up with conflicts in the post install scripts which need to replace the old symbolic link with a new one.
Well, the existing means to handle simultaneous installs of otherwise mutually exclusive packages is the
alternatives mechanism used to handle sendmail vs. postfix and lpd vs. cups.
Yes, symlinks, feeble, but that is the existing mechanism, might as well use if in the distro.
73 de Jeff
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
