SELinux/Policy

The SELinux policy is what contains all the rules that SELinux will enforce. It segregates control from definition, making it possible to distribute the same access control rules towards a multitude of systems.

Control vs definition
A main advantage of having a policy is that it segregates control from definition. The access rules are described / defined in the policy. This policy is then interpreted by the SELinux subsystem to verify and manage access control.



Fully enclosed
A SELinux policy is fully enclosed. All information that SELinux needs to govern access controls is available inside the policy. No additional information is needed.

Modularity
In order to make the SELinux policy more manageable, SELinux supports multiple policy modules. Similar to a kernel configuration, where the entire Linux kernel can be build in a monolithic, single image, but also in a base kernel image with additional, loadable Linux kernel modules.

The base SELinux policy contains rules that cannot be loaded/unloaded, as well as the definitions for the core Linux system controls. Unlike a Linux kernel, even the base policy module can be replaced - but a base policy always needs to be loaded.

Next to the base policies, individual policy modules are defined. These contain all the rules related to an application (or functional coherent set of applications).

Binary representation
The SELinux policy rules are compiled in a binary format - the human readable rules are not loaded verbatim into the SELinux subsystem. The binary representation allows for much smaller memory requirements, as well as optimized policy decisions.

This binary format might change as features are added. When this occurs, the binary version is increased. The table below gives the current list of binary versions and their added feature.

Rebuilding existing policy
To rebuild the existing policy (i.e. build the final from the binary base and policy modules), it is sufficient to call :

If the rules themselves need to be recompiled into binary format, the Gentoo packages that provide the policies need to be rebuild.

This will also reload the policies.

Loading and unloading specific modules
Specific modules can be unloaded and loaded using.

For instance, to unload the screen policy module:

In order to load it again:

Disabling dontaudit rules
It is possible to disable  rules so that SELinux policy deny decisions are always logged, even if the policy developer configured it not to have them displayed.

To re-enable  rules:

Tweaking policies
The existing policy can be enhanced using the  script. This script allows for additional SELinux rules to be defined.

For instance, to assign the  interface for the staff user:

The overview of rules managed by  can be displayed as follows:

Policy packages
Gentoo provides the SELinux policy modules through the  packages. For instance, offers the SELinux policy module for the screen application.

Alongside the standard policy packages, two specific ones are provided:
 * contains the base SELinux policy
 * loads the additional policies that are needed for a functioning system

The latter builds an entire set of additional policy modules which cannot be loaded individually (due to cross-dependencies).

List of policy modules managed by the selinux-base-policy package

By installing a policy package, the policy is compiled into a binary policy module (like ) and then loaded into the actively running policy.