Difference between revisions of "NB PolicyType"

From SELinux Wiki
Jump to: navigation, search
(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 ...)
 
(Policy Versions)
 
(6 intermediate revisions by 2 users not shown)
Line 2: Line 2:
 
This section describes the different type of policy descriptions and versions that can be found within SELinux.
 
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:
+
The type of SELinux policy can described in a number of ways:
  
# Source code - These can be described as: Example, Reference Policy or Custom.
+
# Source code - These can be described as: [[#Example_Policy | Example]], [[#Reference_Policy | Reference Policy]] or [[#Custom_Policy | Custom]]. They are generally written using either [[KernelPolicyLanguage | kernel policy language]], [[NB_RefPolicy#Reference Policy Support Macros | m4 macro support with kernel policy language]], or [[CIL_Language | CIL]].
# The source code descriptions or builds can also be sub-classified as: Monolithic, Base Module or Loadable Module.
+
# They can also be classified as: [[#Monolithic_Policy | Monolithic]], [[#Reference_Policy | 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.
+
# Policies can also be described by the [[#Policy_Functionality_Type | 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.
+
# Classified using language statements - These can be described as [[#Reference_Policy | Modular, Optional]] or [[#Conditional_Policy | Conditional]].
# Binary policy (or kernel policy) - These can be described as Monolithic, Kernel Policy or Binary file.
+
# Binary policy (or kernel policy) - These can be described as [[#Policy_Versions | Monolithic, Kernel Policy or Binary file]].
# Classification can also be on the "policy version" used (examples are version 22, 23 and 24).
+
# Classification can also be on the '[[#Policy_Versions | 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 <tt>'''checkpolicy'''(8)</tt> and <tt>'''secilc'''(8)</tt>  <tt>target_platform</tt> option).
  
 
As can be seen the description of a policy can vary depending on the context.
 
As can be seen the description of a policy can vary depending on the context.
  
 
== Example Policy ==
 
== Example Policy ==
The Example policy is the name used to describe the original SELinux policy source used to build a monolithic<ref name="ftn14"><sup>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 <tt>checkpolicy(8)</tt> command. However the term is sometimes used to refer to the binary policy file (as it is one file that describes the policy).</sup></ref> policy produced by the NSA and is now superseded by the Reference Policy.
+
The Example policy is the name used to describe the original SELinux policy source used to build a [[#Policy_Versions | monolithic]]<ref name="ftn12"><sup>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).</sup></ref> policy produced by the NSA and is now superseded by the Reference Policy.
  
 
== Reference Policy ==
 
== 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.
+
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 [[NB_RefPolicy | The Reference Policy]] 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 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 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:
+
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.
  
<tt>'''selinux-policy-3.6.32-103.fc12.src.rpm'''</tt>
+
== Policy Functionality Based on Name or Type ==
 
+
Generally a policy is installed with a given name such as <tt>targeted</tt>, <tt>mls</tt>, <tt>refpolicy</tt> or <tt>minimum</tt> that attempts to describes its functionality. This name then becomes the entry in:  
For information, the policy RPMs installed on the authors test machine for F-12 are as follows:
+
<pre>
+
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
+
</pre>
+
 
+
=== 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 <tt>targeted</tt>, then the policy will be installed in <tt>/etc/selinux/targeted</tt>).
 
# The directory pointing to the policy location (e.g. if the name is <tt>targeted</tt>, then the policy will be installed in <tt>/etc/selinux/targeted</tt>).
 
# The <tt>SELINUXTYPE</tt> entry in the <tt>/etc/selinux/config</tt> file when it is the active policy (e.g. if the name is <tt>targeted</tt>, then a <tt>SELINUXTYPE=targeted</tt> entry would be in the <tt>/etc/selinux/config</tt> file).
 
# The <tt>SELINUXTYPE</tt> entry in the <tt>/etc/selinux/config</tt> file when it is the active policy (e.g. if the name is <tt>targeted</tt>, then a <tt>SELINUXTYPE=targeted</tt> entry would be in the <tt>/etc/selinux/config</tt> file).
  
This is how the reference policies distributed with F-12 are named, where:
+
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.
: <tt>minimum</tt> - 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.
: <tt>targeted</tt> - 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.
+
 
+
: <tt>mls</tt> - supports server based MLS systems.
+
  
 
The Reference Policy also has a <tt>TYPE</tt> description that describes the type of policy being built by the build process, these are:
 
The Reference Policy also has a <tt>TYPE</tt> 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.
  
: <tt>standard</tt> - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older "targeted" and "strict" versions).
+
The <tt>NAME</tt> and <tt>TYPE</tt> entries are defined in the reference policy <tt>build.conf</tt> file that is described in the [[NB_RefPolicy#Source Configuration Files | Source Configuration Files]] section.  
 
+
: <tt>mcs</tt> - As standard but supports MCS labels.
+
 
+
: <tt>mls</tt> - supports MLS labels as discussed in the [[NB_MLS | Multi-Level Security and Multi-Category Security]] section.
+
 
+
The <tt>NAME</tt> and <tt>TYPE</tt> entries are defined in the reference policy <tt>build.conf</tt> file that is described in the [[NB_RefPolicy | Reference Policy Support]] section.  
+
  
 
== Custom Policy ==
 
== Custom Policy ==
Line 62: Line 46:
  
 
# A customised version of the Example policy.
 
# A customised version of the Example policy.
# A customised version of the Reference Policy (i.e. not the standard distribution version).
+
# 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 the language statements to build a specific policy such as those shown in the Building a Basic Policy section of volume 2.
+
# 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.
  
 
== Monolithic Policy ==
 
== Monolithic Policy ==
A Monolithic policy is an SELinux policy that is compiled from one source file called <tt>policy.conf</tt> (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).  
+
A Monolithic policy is an SELinux policy that is compiled from one source file called (by convention) <tt>policy.conf</tt> (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.
+
An example monolithic policy is the NSAs original [[#Example_Policy | Example Policy]].
  
Monolithic policies are compiled using the <tt>checkpolicy(8)</tt> SELinux command.  
+
Monolithic policies are compiled using the '''checkpolicy''' (8) SELinux command.  
  
 
The Reference Policy supports the building of monolithic policies.
 
The Reference Policy supports the building of monolithic policies.
  
In some cases the policy binary file is also called a monolithic policy.
+
In some cases the kernel policy binary file (see the [[#Binary Policy | Binary Policy]] section) is also called a monolithic policy.
  
 
== Loadable Module Policy ==
 
== Loadable Module Policy ==
Line 82: Line 66:
  
 
# Policy source code that is constructed for a modular policy with a base module and optional loadable modules.
 
# 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 compile and link modules and place them into a 'policy store'.
# Utilities to manage the modules and associated configuration files within the "policy store".
+
# Utilities to manage the modules and associated configuration files within the 'policy store'.
  
The [http://taiga.selinuxproject.org/~rhaines/diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows these components along the top of the diagram. The files contained in the policy store are detailed in the [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]] section.
+
The [http://selinuxproject.org/~rhaines/NB4-diagrams/2-high-level-arch.png High Level SELinux Architecture] diagram shows these components along the top of the diagram. The files contained in the policy store are detailed in the [[PolicyStoreConfigurationFiles | Policy Store Configuration Files]] section.
  
The policy language was extended to handle loadable modules as detailed in the [[PolicyStatements | 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  "[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer]".
+
The policy language was extended to handle loadable modules as detailed in the [[PolicyStatements | Modular 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 "[http://securityblog.org/brindle/2006/07/05/selinux-policy-module-primer/ SELinux Policy Module Primer].
  
=== Optional Policy ===
+
== Optional Policy ==
The loadable module policy infrastructure supports an <tt>optional</tt> 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.
+
The loadable module policy infrastructure supports an [[PolicyStatements#optional | optional policy statement]] that allows policy rules to be defined but only enabled in the binary policy once the conditions have been satisfied.
  
 
== Conditional Policy ==
 
== Conditional Policy ==
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).
+
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 <tt>setsebool(8)</tt> 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:
+
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:
 
<pre>
 
<pre>
setsebool -P ext_gateway_audit=false
+
setsebool -P ext_gateway_audit false
 
</pre>
 
</pre>
  
The conditional policy language statements are the [[ConditionalStatements |  bool]] Statement that defines the boolean flag identifier and its initial status, and the [[ConditionalStatements | if]] that allows certain rules to be executed depending on the state of the boolean value or values.
+
The conditional policy language statements are the <tt>bool</tt> Statement that defines the boolean flag identifier and its initial status, and the <tt>if</tt> Statement that allows certain rules to be executed depending on the state of the boolean value or values.
  
 
== Binary Policy ==
 
== Binary Policy ==
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 <tt>/etc/selinux/config</tt> and <version> is the SELinux policy version supported by the kernel and SELinux tools.
+
This is also know as the kernel policy and is the policy file that is loaded into the kernel and is located at <nowiki>/etc/selinux/<SELINUXTYPE>/policy/policy.<version></nowiki>. Where <tt><nowiki><SELINUXTYPE</nowiki>></tt> is the policy name specified in the SELinux configuration file /etc/selinux/config and <nowiki><version></nowiki> is the SELinux [[#Policy_Versions | policy version]].
  
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.
+
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 <tt>'''SELINUXTYPE=targeted'''</tt> entry identifies the <tt><nowiki><policy_name></nowiki></tt> that will be used to locate and load the active policy:
+
An example /etc/selinux/config file is shown below where the <tt>SELINUXTYPE=targeted</tt> entry identifies the policy name that will be used to locate and load the active policy:
 
<pre>
 
<pre>
 
SELINUX=permissive
 
SELINUX=permissive
Line 113: Line 97:
 
</pre>
 
</pre>
  
From the above example, the actual binary policy file would be located at <tt>/etc/selinux/targeted/policy</tt> and be called policy.24 (as version 24 is supported by F-12):
+
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):
 
<pre>
 
<pre>
/etc/selinux/targeted/policy/policy.24
+
/etc/selinux/targeted/policy/policy.29
 
</pre>
 
</pre>
  
 
== Policy Versions ==
 
== Policy Versions ==
SELinux has a policy database (built by the <tt>libsepol</tt> 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.  
+
SELinux has a policy database (defined in the libsepol library) that describes the format of data held within a [[#Binary_Policy | 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 <tt>sestatus(8)</tt> command will show the current policy version number in its output as follows:
+
The '''sestatus'''(8) command will show the maximum policy version supported by the kernel in its output as follows:
 
<pre>
 
<pre>
 
SELinux status: enabled
 
SELinux status: enabled
SELinuxfs mount: /selinux
+
SELinuxfs mount: /sys/fs/selinux
 +
Loaded policy name targeted
 
Current mode: enforcing
 
Current mode: enforcing
 
Mode from config file: permissive
 
Mode from config file: permissive
Policy version: 24
+
Policy MLS status: enabled
Policy from config file: modular-test
+
Policy deny_unknown status: allowed
 +
Max kernel policy version: 29
 
</pre>
 
</pre>
  
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).
+
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).
  
 
{| border="1"
 
{| border="1"
| '''''policy db Version'''''
+
! policy db Version
| '''''modular db Version'''''
+
! modular db Version
| '''''Description'''''
+
! Description
  
 
|-
 
|-
Line 146: Line 132:
 
| <center>16</center>
 
| <center>16</center>
 
| <center>-</center>
 
| <center>-</center>
| Added Conditional Policy support (the bool feature).
+
| Added [[#Conditional_Policy | Conditional Policy]] support (the bool feature).
  
 
|-
 
|-
Line 176: Line 162:
 
| <center>22</center>
 
| <center>22</center>
 
| <center>7</center>
 
| <center>7</center>
| Added policy capabilities. Allows various kernel options to be enabled as described in the [[NB_LSM | SELinux Filesystem]] section.
+
| Added [[Policy_Configuration_Statements#policycap | policy capabilities]] that allows various kernel options to be enabled as described in the [[NB_LSM#SELinux Filesystem | SELinux Filesystem]] section.
  
 
|-
 
|-
 
| <center>23</center>
 
| <center>23</center>
 
| <center>8</center>
 
| <center>8</center>
| 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 <tt>SELINUX</tt> entry in the /etc/selinux/config file).
+
| 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 <tt>SELINUX</tt> entry in the <tt>/etc/selinux/config</tt> file).
  
 
|-
 
|-
 
| <center>24</center>
 
| <center>24</center>
 
| <center>9 / 10</center>
 
| <center>9 / 10</center>
| Add support for the <tt>typebounds</tt> Statement. This was added to support a hierarchical relationship between two domains in multi-threaded web servers as described in "[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]".
+
| Add support for the <tt>typebounds</tt> statement. This was added to support a hierarchical relationship between two domains in multi-threaded web servers as described in "[http://sepgsql.googlecode.com/files/LCA20090120-lapp-selinux.pdf A secure web application platform powered by SELinux]".
 +
|-
 +
| <center>25</center>
 +
| <center>11</center>
 +
| Add support for file name transition in the <tt>type_transition</tt> rule. Requires kernel 2.6.39 minimum.
 +
 
 +
|-
 +
| <center>26</center>
 +
| <center>12/13</center>
 +
| Add support for a class parameter in the <tt>role_transition</tt> rule.
 +
 
 +
Add support for the <tt>attribute_role</tt> and <tt>roleattribute</tt> statements.
 +
 
 +
These require kernel 2.6.39 minimum.
 +
 
 +
|-
 +
| <center>-</center>
 +
| <center>14</center>
 +
| Separate tunables.
 +
 
 +
|-
 +
| <center>27</center>
 +
| <center>15</center>
 +
| Support setting object defaults for the user, role and range components when computing a new context. Requires kernel 3.5 minimum.
 +
 
 +
|-
 +
| <center>28</center>
 +
| <center>16</center>
 +
| Support setting object defaults for the type component when computing a new context. Requires kernel 3.5 minimum.
 +
 
 +
|-
 +
| <center>29</center>
 +
| <center>17</center>
 +
| Support attribute names within constraints. This allows attributes as well as the types to be retrieved from a kernel policy to assist <tt>'''audit2allow'''(8)</tt> 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.
 +
 
 +
|-
 +
| <center>30</center>
 +
|
 +
| There are two version 30 enhancements that depend on the policy being built:
 +
# For the 'selinux' target platform adds new 'xperm' rules and extends the permission sets as explained in the [[XpermRules | Extended Permission Access Vector Rules]] section. This is to support 'ioctl whitelisting' as explained in the [[XpermRules#ioctl_Operation_Rules | ioctl Operation Rules]] section.
 +
# For the 'xen' target platform support the <tt>devicetreecon</tt> statement and also expand the existing I/O memory range to 64 bits as explained in the [[XENStatements | XEN Statements]] section.
  
 
|}
 
|}
''Table 1: Policy version descriptions ''
 
  
 +
 +
{| style="width: 100%;" border="0"
 +
|-
 +
| [[NB_MLS | '''Previous''']]
 +
| <center>[[NewUsers | '''Home''']]</center>
 +
| <center>[[NB_PandE | '''Next''']]</center>
 +
|}
  
  
Line 196: Line 228:
 
----
 
----
 
<references/>
 
<references/>
 +
 +
[[Category:Notebook]]

Latest revision as of 13:51, 25 September 2015

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:

  1. 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.
  2. They can also be classified as: Monolithic, Base Module or Loadable Module.
  3. Policies can also be described by the type of policy functionality they provide such as: targeted, mls, mcs, standard, strict or minimum.
  4. Classified using language statements - These can be described as Modular, Optional or Conditional.
  5. Binary policy (or kernel policy) - These can be described as Monolithic, Kernel Policy or Binary file.
  6. Classification can also be on the ' policy version' used (examples are version 27, 28 and 29).
  7. 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.

Example Policy

The Example policy is the name used to describe the original SELinux policy source used to build a monolithic[1] policy produced by the NSA and is now superseded by the Reference Policy.

Reference Policy

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:

  1. The directory pointing to the policy location (e.g. if the name is targeted, then the policy will be installed in /etc/selinux/targeted).
  2. 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.

Custom Policy

This generally refers to a policy source that is either:

  1. A customised version of the Example policy.
  2. A customised version of the Reference Policy (i.e. not the standard distribution version e.g. Red Hat policies).
  3. 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.

Monolithic Policy

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:

  1. Policy source code that is constructed for a modular policy with a base module and optional loadable modules.
  2. Utilities to compile and link modules and place them into a 'policy store'.
  3. Utilities to manage the modules and associated configuration files within the 'policy store'.

The High Level SELinux Architecture diagram shows these components along the top of the diagram. The files contained in the policy store are detailed in the Policy Store Configuration Files section.

The policy language was extended to handle loadable modules as detailed in the Modular 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.

Optional Policy

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 Policy

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.

Binary Policy

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:

SELINUX=permissive
SELINUXTYPE=targeted

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):

/etc/selinux/targeted/policy/policy.29

Policy Versions

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
15
4
The base version when SELinux was merged into the kernel.
16
-
Added Conditional Policy support (the bool feature).
17
-
Added support for IPv6.
18
-
Added Netlink support.
19
5
Added MLS support, plus the validatetrans Statement.
20
-
Reduced the size of the access vector table.
21
6
Added support for the MLS range_transition Statement.
22
7
Added policy capabilities that allows various kernel options to be enabled as described in the SELinux Filesystem section.
23
8
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).
24
9 / 10
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".
25
11
Add support for file name transition in the type_transition rule. Requires kernel 2.6.39 minimum.
26
12/13
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.

-
14
Separate tunables.
27
15
Support setting object defaults for the user, role and range components when computing a new context. Requires kernel 3.5 minimum.
28
16
Support setting object defaults for the type component when computing a new context. Requires kernel 3.5 minimum.
29
17
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.
30
There are two version 30 enhancements that depend on the policy being built:
  1. For the 'selinux' target platform adds new 'xperm' rules and extends the permission sets as explained in the Extended Permission Access Vector Rules section. This is to support 'ioctl whitelisting' as explained in the ioctl Operation Rules section.
  2. For the 'xen' target platform support the devicetreecon statement and also expand the existing I/O memory range to 64 bits as explained in the XEN Statements section.


Previous
Home
Next



  1. 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).