We finish this chapter by explaining how SELinux policy modules can be distributed across multiple systems.
To distribute SELinux policies, complete the following steps:
Take into account the different system configurations to which the SELinux policies need to be distributed:
If multiple systems have different SELinux policy releases to be active, then build the SELinux policy module against each of these implementations. This is heavily distribution specific. For instance, on Gentoo, this is the version of the
sec-policy/selinux-basepackage. On Red Hat and derived distributions, this is the version of theselinux-policypackage.If multiple SELinux policy types are active (such as
mcs,targeted, andstrict) and there are both MLS-enabled as well as MLS-disabled policies, then the SELinux policy module will need to be built against both an MLS-enabled policy as well as an MLS-disabled policy. The output ofsestatuswill tell us whether MLS is enabled on an active policy or not:~$ sestatus | grep MLS Policy MLS status: enabled
Package the resulting
.ppfiles and distribute them to the various systems. It is a common best practice to place the.ppfiles inside/usr/share/selinux/mcs/(this is for an SELinux policy store namedmcs, you can adjust it where needed).On each system, make sure that the
.ppfile is loaded throughsemodule –I policyfile.pp.
SELinux policy modules (the files ending with .pp) contain everything SELinux needs to activate the policy. By distributing these files across many systems (and loading it through the semodule command), these systems receive the wanted updates against their current SELinux policy.
Once loaded (and this only needs to happen once, as a loaded module is retained even after the system reboots), one does not really need the .pp files anymore (loaded modules are copied inside /etc/selinux). However, it is recommended that you keep the policies there so that administrators can reload policies as needed; this might help in troubleshooting the SELinux policy and system permission issues.
There are a few caveats to take into account though:
Changes in interfaces
Kernel version changes
MLS-enabled or MLS-disabled policies
The .pp files contain all rules that SELinux needs to enforce the additional policy rules. This includes the (expanded) rules that were part of the interface definition files (the .if files) of the module itself as well as the interfaces referred to by the policy module.
When an update against an interface occurs, then all SELinux policy modules that might be affected by the change need to be rebuilt. As there is no simple way to know if a module needs to be rebuilt or not, it is recommended that you rebuild all policy modules every time a change has occurred to at least one interface.
Distributions will handle the rebuilding of the policies and the distribution of the rebuilt policies themselves, but for custom policy modules, we need to do this ourselves.
New kernel releases might include updates against the SELinux subsystem. When these updates provide additional features, the binary representation of a policy might be updated. This is then reflected in the binary version of the policy that the kernel supports.
Binary versions are backward compatible, so a system that supports a maximum version of 28 (SELinux's binary versions are integers that are incremented with every change) will also support loading policy modules of a lower binary version:
~# sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: mcs Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: denied Max kernel policy version: 28
Note
When the binary version of an SELinux policy module is higher than the maximum kernel policy version, this SELinux policy module will not load on the target system. A higher version means that the policy uses features that are only available in kernels that support this version, so the administrator will need to update the kernels on those systems to support the higher version or update the SELinux policy module to not use these features so that a rebuild creates a lower-versioned binary SELinux policy module.
SELinux policy modules might contain sensitivity-related information. When a policy module is built, information is added to reflect whether it is built against an MLS-enabled system or not.
Therefore, if we have hosts that have diverse policy usages (some policy stores are MLS-enabled and some are MLS-disabled), then the SELinux policy module will need to be built against both and distributed separately.
Usually, this is done by providing SELinux policy modules for each particular SELinux policy type (be it mcs, strict, or targeted).