NB PolicyType

From SELinux Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 20:48, 13 September 2010 (edit)
Jaxelson (Talk | contribs)

← Previous diff
Revision as of 12:20, 3 April 2013 (edit) (undo)
RichardHaines (Talk | contribs)

Next diff →
Line 4: Line 4:
The types of SELinux policy can described in a number of ways: The types 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]]
-# The source code descriptions or builds can also be sub-classified as: Monolithic, Base Module or Loadable Module.+# The source code descriptions or builds can also be sub-classified as: [[#Policy_Versions 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 22, 23 and 24).
-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="ftn1">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).</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 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 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:+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.
-<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-17 are named, where:
-: <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.+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>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.+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.
-: <tt>mls</tt> - supports server based MLS systems.+mls - 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:
-: <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).+standard - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older 'targeted' and 'strict' versions).
-: <tt>mcs</tt> - As standard but supports MCS labels.+mcs - 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.+mls - supports MLS labels as discussed in the [http://selinuxproject.org/page/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. +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 [http://selinuxproject.org/page/NB_RefPolicy#Source_Configuration_Files 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 http://userspace.selinuxproject.org/trac/wiki/CilDesign]).
== Custom Policy == == Custom Policy ==
Line 62: Line 53:
# 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 [http://selinuxproject.org/page/PolicyStatements 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 <tt>checkpolicy(8)</tt> SELinux command. +An example monolithic policy is the NSAs original [[#Example_Policy | Example Policy]]. 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.
Line 79: Line 68:
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). 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:+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. # 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 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 [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 [http://selinuxproject.org/page/PolicyStoreConfigurationFiles Policy Store Configuration Files] section.
 +The policy language was extended to handle loadable modules as detailed in the [http://selinuxproject.org/page/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]".
=== 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 <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.
 + 
 +Example loadable modules with <tt>optional</tt> statements are used in the message filter example contained in the Notebook source tarball.
== 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. 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 always 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 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. 
-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 103:
</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.26 (as version 26 is supported by F-16):
<pre> <pre>
-/etc/selinux/targeted/policy/policy.24+/etc/selinux/targeted/policy/policy.26
</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 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 <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 number 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
Current mode: enforcing Current mode: enforcing
Mode from config file: permissive Mode from config file: permissive
-Policy version: 24+Policy version: 26
Policy from config file: modular-test Policy from config file: modular-test
</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 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''
{| border="1" {| border="1"
-| '''''policy db Version'''''+! policy db Version
-| '''''modular db Version'''''+! modular db Version
-| '''''Description'''''+! Description
|- |-
Line 176: Line 169:
| <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 capabilities that allows various kernel options to be enabled as described in the [http://selinuxproject.org/page/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]".
-|}+|-
-''Table 1: Policy version descriptions ''+| <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.
 +
 +|}

Revision as of 12:20, 3 April 2013

Contents

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:

  1. Source code - These can be described as: Example, Reference Policy or Custom
  2. The source code descriptions or builds can also be sub-classified as: #Policy_Versions 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 22, 23 and 24).

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

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

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

  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 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".

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.

Example loadable modules with optional statements are used in the message filter example contained in the Notebook source tarball.

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

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.26 (as version 26 is supported by F-16):

/etc/selinux/targeted/policy/policy.26

Policy Versions

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



  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).
Personal tools