From SELinux Wiki
Types of SELinux Policy
This section describes the different type of policy descriptions and versions that can be found within SELinux.
The types of SELinux policy can described in a number of ways:
- Source code - These can be described as: Example, Reference Policy or Custom
- The source code descriptions or builds can also be sub-classified as: #Policy_Versions Monolithic, Base Module or Loadable Module.
- Policies can also be described by the type of policy functionality they provide such as: targeted, mls, mcs, standard, strict or minimum.
- Classified using language statements - These can be described as Modular, Optional or Conditional.
- Binary policy (or kernel policy) - These can be described as Monolithic, Kernel Policy or Binary file.
- Classification can also be on the ' policy version' used (examples are version 22, 23 and 24).
As can be seen the description of a policy can vary depending on the context.
Note that this section only gives an introduction to the reference policy, the installation, configuration and building of a policy using the source code is in the http://selinuxproject.org/page/NB_RefPolicy section.
The Reference Policy is now the standard policy source used to build SELinux policies, and its main aim is to provide a single source tree with supporting documentation that can be used to build policies for different purposes such as: confining important daemons, supporting MLS / MCS and locking down systems so that all processes are under SELinux control.
The Reference Policy is now used by all major distributions of SELinux, however each distribution makes its own specific changes to support their 'version of the Reference Policy'. For example, the F-17 distribution is based on a specific build of the standard Reference Policy that is then modified and distributed by Red Hat as an RPM.
Policy Functionality Based on Name or Type
Generally a policy is installed with a given name such as targeted, mls, refpolicy or minimum that attempts to describes its functionality. This name then becomes the entry in:
- The directory pointing to the policy location (e.g. if the name is targeted, then the policy will be installed in /etc/selinux/targeted).
- The SELINUXTYPE entry in the /etc/selinux/config file when it is the active policy (e.g. if the name is targeted, then a SELINUXTYPE=targeted entry would be in the /etc/selinux/config file).
This is how the reference policies distributed with F-17 are named, where:
minimum - supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space. Red Hat pre-configure MCS support within this policy.
targeted - supports a greater number of confined daemons and can also confine other areas and users. Red Hat pre-configure MCS support within this policy.
mls - supports server based MLS systems.
The Reference Policy also has a TYPE description that describes the type of policy being built by the build process, these are:
standard - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older 'targeted' and 'strict' versions).
mcs - As standard but supports MCS labels.
mls - supports MLS labels as discussed in the Multi-Level Security and Multi-Category Security section.
The NAME and TYPE entries are defined in the reference policy build.conf file that is described in the Source Configuration Files section.
Note that at some stage in the future the Reference Policy may be replaced by the Common Intermediate Language (CIL) service that is under development (see http://userspace.selinuxproject.org/trac/wiki/CilDesign).
This generally refers to a policy source that is either:
- A customised version of the Example policy.
- A customised version of the Reference Policy (i.e. not the standard distribution version e.g. Red Hat policies).
- A policy that has been built using policy language statements to build a specific policy such as the basic policy built in the Notebook source tarball.
A Monolithic policy is an SELinux policy that is compiled from one source file called (by convention) policy.conf (i.e. it does not use the Loadable Module Policy statements and infrastructure which therefore makes it suitable for embedded systems as there is no policy store overhead).
An example monolithic policy is the NSAs original Example Policy. Monolithic policies are compiled using the checkpolicy (8) SELinux command.
The Reference Policy supports the building of monolithic policies.
In some cases the policy binary file is also called a monolithic policy.
Loadable Module Policy
The loadable module infrastructure allows policy to be managed on a modular basis, in that there is a base policy module that contains all the core components of the policy (i.e. the policy that should always be present), and zero or more modules that can be loaded and unloaded as required (for example if there is a module to enforce policy for ftp, but ftp is not used, then that module could be unloaded).
There are number of parts that form the infrastructure:
- Policy source code that is constructed for a modular policy with a base module and optional loadable modules.
- Utilities to compile and link modules and place them into a 'policy store'.
- Utilities to manage the modules and associated configuration files within the 'policy store'.
The policy language was extended to handle loadable modules as detailed in the Policy Support Statements section. For a detailed overview on how the modular policy is built into the final binary policy for loading into the kernel, see the "SELinux Policy Module Primer".
The loadable module policy infrastructure supports an optional policy statement that allows policy rules to be defined but only enabled in the binary policy once the conditions have been satisfied.
Example loadable modules with optional statements are used in the message filter example contained in the Notebook source tarball.
Conditional policies can be implemented in monolithic or loadable module policies and allow parts of the policy to be enabled or not depending on the state of a boolean flag. This is often used to enable or disable features within the policy (i.e. change the policy enforcement rules).
The boolean flag status is held in kernel and can be changed using the setsebool(8) command either persistently across system re-boots or temporarily (i.e. only valid until a re-boot). The following example shows a persistent conditional policy change:
setsebool -P ext_gateway_audit false
The conditional policy language statements are the bool Statement that defines the boolean flag identifier and its initial status, and the if Statement that allows certain rules to be executed depending on the state of the boolean value or values.
This is also know as the kernel policy and is the policy file that is loaded into the kernel and is always located at /etc/selinux/<SELINUXTYPE>/policy/policy.<version>. Where <SELINUXTYPE> is the policy name specified in the SELinux configuration file /etc/selinux/config and <version> is the SELinux policy version.
An example /etc/selinux/config file is shown below where the SELINUXTYPE=targeted entry identifies the policy name that will be used to locate and load the active policy:
From the above example, the actual binary policy file would be located at /etc/selinux/targeted/policy and be called policy.26 (as version 26 is supported by F-16):
SELinux has a policy database (defined the libsepol library) that describes the format of data held within a binary policy, however, if any new features are added to SELinux (generally language extensions) this can result in a change to the policy database. Whenever the policy database is updated, the policy version is incremented.
The sestatus(8) command will show the maximum policy version number supported by the kernel in its output as follows:
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux Current mode: enforcing Mode from config file: permissive Policy version: 26 Policy from config file: modular-test
The F-16 kernel policy version is '26' with Table 1 describing the different versions. There is also another version that applies to the modular policy, however the main policy database version is the one that is generally quoted (some SELinux utilities give both version numbers).
Table 1: Policy version descriptions
|policy db Version||modular db Version||Description|
| || ||The base version when SELinux was merged into the kernel.|
| || ||Added Conditional Policy support (the bool feature).|
| || ||Added support for IPv6.|
| || ||Added Netlink support.|
| || ||Added MLS support, plus the validatetrans Statement.|
| || ||Reduced the size of the access vector table.|
| || ||Added support for the MLS range_transition Statement.|
| || ||Added policy capabilities that allows various kernel options to be enabled as described in the SELinux Filesystem section.|
| || ||Added support for the permissive statement. This allows a domain to run in permissive mode while the others are still confined (instead of the all or nothing set by the SELINUX entry in the /etc/selinux/config file).|
| || ||Add support for the typebounds statement. This was added to support a hierarchical relationship between two domains in multi-threaded web servers as described in "A secure web application platform powered by SELinux".|
| || ||Add support for file name transition in the type_transition rule. Requires kernel 2.6.39 minimum.|
| || || Add support for a class parameter in the role_transition rule.
Add support for the attribute_role and roleattribute statements.
These require kernel 2.6.39 minimum.
| || ||Separate tunables.|
| || ||Support setting object defaults for the user, role and range components when computing a new context. Requires kernel 3.5 minimum.|
| || ||Support setting object defaults for the type component when computing a new context. Requires kernel 3.5 minimum.|
| || ||Support attribute names within constraints. This allows attributes as well as the types to be retrieved from a kernel policy to assist audit2allow(8) etc. to determine what attribute needs to be updated. Note that the attribute does not determine the constraint outcome, it is still the list of types associated to the constraint.|
- ↑ The term 'monolithic' generally means a single policy source is used to create the binary policy file that is then loaded as the 'policy' using the checkpolicy(8) command. However the term is sometimes used to refer to the binary policy file (as it is one file that describes the policy).