Types of SELinux Policy
This section describes the different type of policy descriptions and versions that can be found within SELinux.
The type of SELinux policy can described in a number of ways:
- Source code - These can be described as: Example, Reference Policy or Custom. They are generally written using either kernel policy language, m4 macro support with kernel policy language, or CIL.
- They can also be classified as: 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 27, 28 and 29).
- Policy can also be generated depending on the target platform of either 'selinux' (the default) or 'xen' (see the SELinux policy generation tools checkpolicy(8) and secilc(8) target_platform option).
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 this is contained in The Reference Policy section.
The Reference Policy is now the standard policy source used to build Linux based 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 Linux, however each distribution makes its own specific changes to support their 'version of the Reference Policy'. For example, the F-20 distribution is based on a specific build of the standard Reference Policy that is then modified and distributed by Red Hat as a number of RPMs.
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-20 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 server based MLS systems.
The NAME and TYPE entries are defined in the reference policy build.conf file that is described in the Source Configuration Files section.
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 kernel policy binary file (see the Binary Policy section) 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 components 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 "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.
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 at run time. 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 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.
The binary policy can be built from source files supplied by the Reference Policy or custom built source files.
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.29 (as version 29 is supported by F-20):
SELinux has a policy database (defined in 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 supported by the kernel in its output as follows:
SELinux status: enabled SELinuxfs mount: /sys/fs/selinux Loaded policy name targeted Current mode: enforcing Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 29
The following table describes the different versions, although note that 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).
|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.
||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. Requires kernel 3.14 minimum.|
|| There are two version 30 enhancements that depend on the policy being built:
- 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).