From SELinux Wiki
|Revision as of 14:57, 16 May 2010 (edit)
RichardHaines (Talk | contribs)
(New page: = 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 ...)
← Previous diff
|Revision as of 20:48, 13 September 2010 (edit) (undo)
Jaxelson (Talk | contribs)
Next diff →
|Line 196:||Line 196:|
Revision as of 20:48, 13 September 2010
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: 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.
The Example policy is the name used to describe the original SELinux policy source used to build a monolithic policy produced by the NSA and is now superseded by the Reference Policy.
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 contained in the Reference Policy.
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-12 distribution is based on a specific build of the standard Reference Policy that is then modified and distributed by Red Hat as an RPM. The release numbers will vary however this Notebook uses:
For information, the policy RPMs installed on the authors test machine for F-12 are as follows:
selinux-policy-3.6.32-103.fc12.noarch selinux-policy-doc-3.6.32-103.fc12.noarch selinux-policy-minimum-3.6.32-103.fc12.noarch selinux-policy-mls-3.6.32-103.fc12.noarch selinux-policy-targeted-3.6.32-103.fc12.noarch
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 normally 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-12 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 (this targeted version also supports the older "strict" version). 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 Reference Policy Support 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).
- A policy that has been built using the language statements to build a specific policy such as those shown in the Building a Basic Policy section of volume 2.
A Monolithic policy is an SELinux policy that is compiled from one source file called 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. A simple monolithic policy is shown in Volume 2.
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 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 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. The example loadable modules shown in the Building a Basic Policy section of volume 2 use this feature.
Conditional policies can be implemented in monolithic or loadable module policies and allow 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 that allows certain rules to be executed depending on the state of the boolean value or values.
The binary policy is the policy file that is loaded into the kernel and is always located at /etc/selinux/<policy_name>/policy and is called policy.<version>. Where <policy_name> is the policy name specified in the SELinux configuration file /etc/selinux/config and <version> is the SELinux policy version supported by the kernel and SELinux tools.
The binary policy can be built from source files supplied by the Example Policy, the Reference Policy or custom built source files as described in the Building a Basic Policy section of volume 2.
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.24 (as version 24 is supported by F-12):
SELinux has a policy database (built by 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 current policy version number in its output as follows:
SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: permissive Policy version: 24 Policy from config file: modular-test
The F-12 policy version is "24" with Table 3 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 (e.g. apol) 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. Allows various kernel options to be enabled as described in the SELinux Filesystem section.|
| || ||Added support for the permissive Statement. This allows a module 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".|
Table 1: Policy version descriptions
- ↑ 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).