Andrew Farris wrote:
On Tue, 2004-05-25 at 14:47 -0400, Daniel J Walsh wrote:
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)
At this time.. since a 'clean break' is desired and still fairly doable
it would be a good idea to consider more than two policies -- the
changes made now should at least consider the repercussions of sysadmins
adding their own customized policies.. in parallel rather than over the
top of these two.
This design allows for more than two policies. Basically any directory
name within /etc/selinux could be a policy. All that really happens is
that libselinux will prepend /etc/selinux/POLICYTYPE and then postpend
"policy" and "contexts" on the end and look for its files there. So
you you define a POLICYTYPE=FarrisPolicy and setup
/etc/selinux/FarrisPolicy/ correctly your policy will be used.
2. Both packages obsolete the current policy rpm.
3. We want both policy files to be installable and not conflict with
each other.
4. Policy files will be installed in the /etc/selinux/(strict|targeted)
directory.
Under this tree there will be at least three additional directiories
These separated trees should be a general enough method for additional
policies.
They are
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.
system-config-security should handle setting this and recognizing the
presence of additional policies as well -- libselinux handles this for
s-c-s?
We can look into this. Basically allow the selection of all directories
under /etc/selinux/. Or maybe make sure there is a policy and context
file in each directory.
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.
On install it may be reasonable to set the context if the current value
was unknown.. but it may be annoying if installing a default policy
while a custom policy was in use. Perhaps a defined 'custom' option
should be considered that these scripts would honor as valid, or the
'custom' name could be mandated to be an existing directory
under /etc/security/selinux (meaning only that it is there rather than
actually checking the contents of the directory in the rpm install
script).
Right so if you do not have POLICYTYPE set it will be set to the first
policy RPM that is installed. If it is set then no RPM will change it.
The user will have to manually change it.
# Select the type of policy that you are running current values are
# strict and targeted
# strict, targeted, or custom
#
SELINUXTYPE=strict
Perhaps this consideration is something for the next 'clean break'
instead of now, but it looks like a good time to handle is as generally
as possible.
