| If '<tt>y</tt>' sysadm will be allowed to directly run init scripts, instead of requiring the run_init tool. This is a build option instead of a tunable since role transitions do not work in conditional policy. This option controls direct_sysadm_daemon policy blocks.

| If '<tt>y</tt>' sysadm will be allowed to directly run init scripts, instead of requiring the run_init tool. This is a build option instead of a tunable since role transitions do not work in conditional policy. This option controls direct_sysadm_daemon policy blocks.

|-

|-

| '''MONOLITHIC'''

| '''MONOLITHIC'''

−

| Boolean (<tt>y|n</tt>)

+

| Boolean (<tt><nowiki>y|n</nowiki></tt>)

| If '<tt>y</tt>' a monolithic policy is built, otherwise a modular policy is built.

| If '<tt>y</tt>' a monolithic policy is built, otherwise a modular policy is built.

|-

|-

| '''UBAC'''

| '''UBAC'''

−

| Boolean (<tt>y|n</tt>)

+

| Boolean (<tt><nowiki>y|n</nowiki></tt>)

| If '<tt>y</tt>' User Based Access Control policy is built. The default for Red Hat is '<tt>n</tt>'. These are defined as constraints in the <tt>policy/constraints</tt> file. Note Version 1 of the Reference Policy did not have this entry and defaulted to Role Based Access Control.

| If '<tt>y</tt>' User Based Access Control policy is built. The default for Red Hat is '<tt>n</tt>'. These are defined as constraints in the <tt>policy/constraints</tt> file. Note Version 1 of the Reference Policy did not have this entry and defaulted to Role Based Access Control.

Line 469:

Line 469:

|-

|-

| '''QUIET'''

| '''QUIET'''

−

| Boolean (<tt>y|n</tt>)

+

| Boolean (<tt><nowiki>y|n</nowiki></tt>)

| If '<tt>y</tt>' the build system will only display status messages and error messages. This option has no effect on policy.

| If '<tt>y</tt>' the build system will only display status messages and error messages. This option has no effect on policy.

Line 581:

Line 581:

Generally it is up to the policy writer to decide which modules are in the base and those that are loadable, however there are some modules that MUST be in the base module. To highlight this there is a special entry at the start of the modules interface file (.if) that has the entry <required val='true'> as shown below (taken from the kernel.if file):

Generally it is up to the policy writer to decide which modules are in the base and those that are loadable, however there are some modules that MUST be in the base module. To highlight this there is a special entry at the start of the modules interface file (.if) that has the entry <required val='true'> as shown below (taken from the kernel.if file):

−

Pre>

+

<pre>

## <summary>

## <summary>

##Policy for kernel threads, proc filesystem,

##Policy for kernel threads, proc filesystem,

Line 612:

Line 612:

| system

| system

| application

| application

−

| Policy for user executable applications.

+

| <nowiki>Policy for user executable applications.

−

All the interface calls start with 'application_'.

+

All the interface calls start with 'application_'.</nowiki>

|-

|-

| system

| system

| setrans

| setrans

−

| Policy for the SELinux MLS/MCS label translation service.

+

| <nowiki>Policy for the SELinux MLS/MCS label translation service.

All the interface calls start with 'setrans_'.

All the interface calls start with 'setrans_'.

−

+

</nowiki>

|-

|-

| kernel

| kernel

| corecommands

| corecommands

−

| Core policy for shells, and generic programs in:

+

| <nowiki>Core policy for shells, and generic programs in:

/bin, /sbin, /usr/bin, and /usr/sbin.

/bin, /sbin, /usr/bin, and /usr/sbin.

The .fc file sets up the labels for these items.

The .fc file sets up the labels for these items.

−

All the interface calls start with 'corecmd_'.

+

All the interface calls start with 'corecmd_'.</nowiki>

|-

|-

Line 1,232:

Line 1,232:

make load

make load

</pre>

</pre>

+

<pre>

# Finally copy over two files that are not automatically

# Finally copy over two files that are not automatically

# managed by the build process. These are held in the

# managed by the build process. These are held in the

Line 1,260:

Line 1,261:

</pre>

</pre>

−

Note that the binaries would not be an exact comparison due to time stamps etc., therefore the SETools sediffx utility should be run against the two binary policies<ref name="ftn62">Be aware that comparing these two policies on a low specification machine will take hours. It is best to select a few items for comparison first.</ref> which should show that they are the same and give the results shown in [http://taiga.selinuxproject.org/~rhaines/diagrams/5-5-Two-Policies.png The two "targeted" policies should be the same using <tt>sediffx''</tt>] screen shots.

+

Note that the binaries would not be an exact comparison due to time stamps etc., therefore the SETools sediffx utility should be run against the two binary policies<ref name="ftn62">Be aware that comparing these two policies on a low specification machine will take hours. It is best to select a few items for comparison first.</ref> which should show that they are the same and give the results shown in [http://taiga.selinuxproject.org/~rhaines/diagrams/5-5-Two-Policies.png "Comparing the two "targeted" policies using <tt>sediffx</tt>"] screen shots.

−

+

=== Running with the new Policy ===

=== Running with the new Policy ===

Line 1,580:

Line 1,580:

....

....

}

}

−

<pre>

+

</pre>

==== gen_require Macro ====

==== gen_require Macro ====

Line 1,645:

Line 1,645:

|-

|-

| optional_statements

| optional_statements

−

| These statements consist of those allowed in the policy language optional Statement. However they can also be [#8.6.1.6.interface Macro|outline interface], [#8.6.1.7.template Macro|outline template] or support macro calls.

+

| These statements consist of those allowed in the policy language optional Statement. However they can also be [[NB_RefPolicy#interface_Macro | interface]], [[NB_RefPolicy#template_Macro | template]] or support macro calls.

|}

|}

Line 1,680:

Line 1,680:

'''Expanded Macro:'''

'''Expanded Macro:'''

−

+

<pre>

# This is the expanded macro from the tmp/ftp.tmp file showing

# This is the expanded macro from the tmp/ftp.tmp file showing

# the policy language statements with both optional levels

# the policy language statements with both optional levels

Line 1,748:

Line 1,748:

<pre>

<pre>

gen_tunable(boolean_name,boolean_value)

gen_tunable(boolean_name,boolean_value)

−

</pre

+

</pre>

+

'''Where:'''

'''Where:'''

Line 1,844:

Line 1,845:

fs_manage_nfs_files(ftpd_t)

fs_manage_nfs_files(ftpd_t)

')

')

−

<pre>

+

</pre>

'''Expanded Macro:'''

'''Expanded Macro:'''

<pre>

<pre>

Line 1,986:

Line 1,987:

* A template interface allows an application to be run in a domain based on user / role information to isolate different instances.

* A template interface allows an application to be run in a domain based on user / role information to isolate different instances.

−

Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[NB_RefPolicy#Reference_Policy_Documentation | documentation].

+

Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[NB_RefPolicy#Reference_Policy_Documentation | documentation]].

'''The macro definition is:'''

'''The macro definition is:'''

Line 2,291:

Line 2,292:

# Use the boolean in the module files with an if Statement as shown in the example.

# Use the boolean in the module files with an if Statement as shown in the example.

−

Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [#8.2.4.Reference Policy Documentation|outline documentation].

+

Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the [[NB_RefPolicy#Reference Policy Documentation | documentation]].

The Reference Policy

Introduction

The Reference Policy is now the standard policy source used to build SELinux policies. This provides 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 type policies and locking down systems so that all processes are under SELinux control.

This section details how the Reference Policy is:

Constructed and types of policy builds supported.

Installation as a full Reference Policy source or as Header files.

Modifying the configuration files to build new policies.

Adding new modules to the build.

Notebook Reference Policy Information

This section makes use of the F-12 distribution that is built from the standard Reference Policy VERSION=20090730[1]. This is modified and distributed by Red Hat as the following RPM:

This core source code is then used to build various policy RPMs that are distributed by Red Hat as:

selinux-policy-3.6.32-103.fc12.noarch - Contains the SELinux /etc/selinux/config file, man pages and the "Policy Header" development environment that is located at /usr/share/selinux/devel

selinux-policy-doc-3.6.32-103.fc12.noarch - Contains the html policy documentation that is located at /usr/share/doc/selinux-policy-3.6.32/html

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

These three rpms contain policy configuration files and the packaged policy modules (*.pp). These will be used to build the particular policy type in /usr/share/selinux/<policy_name>, the install process will then install the policy in the appropriate /etc/selinux/<policy_name> directory.

Reference Policy Overview

The Reference Policy can be used to build two different formats of a policy:

Loadable Module Policy - A policy that has a base module for core services and has the ability to load / unload modules to support applications as required[3]. This is now the standard used by GNU / Linux distributions.

Monolithic Policy - A policy that has all the required policy information in a single base policy.

Each of the policy types are built using module files that define the specific modules required by the policy as detailed in the Reference Policy Module Files section. Note that the monolithic policy is built using the the same module files, however they are all assembled into a single "base" source file.

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" (as this section should show as the Red Hat F-12 policy distribution has a slightly different build to the standard Reference PolicyVERSION=2.20090730).

There are tools such as SLIDE (SELinux integrated development environment) that can be used to make the task of policy development and testing easier when using the Reference Policy source or headers. SLIDE is an Eclipse plugin and details can be found at:

As "Policy Headers". This is the most common way to distribute the Reference Policy. Basically, the modules that make up "the distribution" are pre-built and then linked to form a base and optional modules. The "headers" that make-up the policy are then distributed along with makefiles and documentation. A policy writer can then build policy using the core modules supported by the distribution, and using development tools they can add their own policy modules. The Reference Policy Headers section describes how these are installed and used to build modules.

The policy header files for F-12 are distributed in a number of rpms as follows:

selinux-policy-3.6.32-103.fc12.noarch - This package contains the SELinux /etc/selinux/config file, man pages and the "Policy Header" development environment that is located at /usr/share/selinux/devel

selinux-policy-doc-3.6.32-103.fc12.noarch - This package contains the html policy documentation that is located at /usr/share/doc/selinux-policy-3.6.32/html

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

These three packages contain policy configuration files and policy modules (*.pp files) for the particular policy type to be installed. These files are used to build the policy type in /usr/share/selinux/<policy_name> and then install the policy in the /etc/selinux/<policy_name> directory.

Normally only one policy would be installed and active, however for development purposes all three can be installed.

Policy Functionality

As can be seen from the policies distributed with F-12 above, they can be classified by the name of the functionality they support (taken from the NAME entry of the build.conf as shown in Table 2), for example the Red Hat policies support[4]:

mminimum - supports a minimal set of confined daemons within their own domains. The remainder run in the unconfined_t space.

mls - supports server based MLS systems.

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

For information, the Reference Policy supports the following types (taken from the TYPE entry of the build.conf as shown in Table 2):

standard - supports confined daemons and can also confine other areas and users (this is an amalgamated version of the older "targeted" and "strict" versions).

Reference Policy Module Files

1. A private policy file that contains statements required to enforce policy on the specific GNU / Linux service being defined within the module. These files are named <module_name>.te.

For example the ada.te file shown below has two statements:

a) one to state that the ada_t process has permission to write to the stack and memory allocated to a file.

b) one that states that if the unconfined module is loaded, then allow the ada_t domain unconfined access. Note that if the flow of this statement is followed it will be seen that many more interfaces and macros are called to build the final raw SELinux language statements.

2. An external interface file that defines the services available to other modules. These files are named <module_name>.if.

For example the ada.if file shown below has two interfaces defined for other modules to call (see also the Example Documentation Screen Shot that shows a screen shot of the documentation that can be automatically generated):

a) ada_domtrans - that allows another module (running in domain $1) to run the ada application in the ada_t domain.

b) ada_run - that allows another module to run the ada application in the ada_t domain (via the ada_domtrans interface), then associate the ada_t domain to the caller defined role ($2) and terminal ($3).

Provided of course that the caller domain has permission.

It should be noted that there are two types of interface specification:

Access Interfaces - These are the most common and define interfaces that .te modules can call as described in the ada examples. They are generated by the interface macro as detailed in the the interface Macro section.

Template Interfaces - These are required whenever a module is required in different domains and allows the type(s) to be redefined by adding a prefix supplied by the calling module. The basic idea is to set up an application in a domain that is suitable for the defined SELinux user and role to access but not others. These are generated by the template macro as detailed in the template Macro section that also explains the openoffice.if template.

3. A file labeling file that defines the labels to be added to files for the specified module. These files are named <module_name>.fc. The build process will amalgamate all the .fc files and finally form the file_contexts file that will be used to label the filesystem.

For example the ada.fc file shown below requires that the specified files are all labeled system_u:object_r:ada_exec_t:s0.

The <module_name> must be unique within the reference policy source tree and should reflect the specific GNU / Linux service being enforced by the policy.

Reference Policy Documentation

One of the advantages of the reference policy is that it is possible to automatically generate documentation as a part of the build process. This documentation is defined in XML and generated as HTML files suitable for viewing via a browser.

The documentation for F-12 can be found in the following locations:

Distributed as Policy Headers - /usr/share/doc/selinux-policy-<version>/html. Where <version> is the version number of the Red Hat release, for the build used in this Notebook the location is:

/usr/share/doc/selinux-policy-3.6.32/html

Distributed as Policy Source - <location>/src/policy/doc/html. Where <location> is the location of the installed source after make install-src has been executed as described in the Installing The Reference Policy Source section. The documentation can then be generated using make html, where for the build used in this Notebook the location is:

Reference Policy Source

The source has a README file containing information on the configuration and installation processes that has been used within this section (and updated with the authors comments as necessary). There is also a VERSION file that contains the Reference Policy release date which can be used to obtain the original source from the repository located at:

Reference Policy Files and Directories

Table 1 shows the major files and their directories with a description of each taken from the README file. All directories are relative to the root of the Reference Policy source directory ./policy.

Two of these configuration files (build.conf and modules.conf) are further detailed in the Source Configuration Files section as they define how the policy will be built.

During the build process, a file is generated in the ./policy directory called either policy.conf or base.conf depending whether a monolithic or modular policy is being built. This file is explained in the Modular Policy Build Structure section.

File / Directory Name

Comments

Makefile

General rules for building the policy.

Rules.modular

Makefile rules specific to building loadable module policies.

Rules.monolithic

Makefile rules specific to building monolithic policies.

build.conf

Options which influence the building of the policy, such as the policy type and distribution.

config/appconfig-<type>

Application configuration files for all configurations of the Reference Policy where <type> is taken from the build.conf TYPE entry that are currently: standard, MLS and MCS). These files are used by SELinux-aware programs.

config/local.users

The file read by load policy for adding SELinux users to the policy on the fly.

Note that this file is not used in the F-12 modular policy build.

doc/html/*

When make html has been executed, contains the in-policy XML documentation, presented in web page form

doc/policy.dtd

The doc/policy.xml file is validated against this DTD.

doc/policy.xml

This file is generated/updated by the conf and html make targets. It contains the complete XML documentation included in the policy.

This file defines the access vectors. Common prefixes for access vectors may be defined at the beginning of the file. After the common prefixes are defined, an access vector may be defined for each security class.

This file is generated/updated by the conf make target. It contains the booleans in the policy, and their default values. If tunables are implemented as booleans, tunables will also be included. This file will be installed as the /etc/selinux/NAME/booleans file (note that this is not true for F-12 or any system that implements the modular policy - see the Booleans, Global Booleans and Tunable Booleans section).

This file defines additional constraints on permissions in the form of boolean expressions that must be satisfied in order for specified permissions to be granted. These constraints are used to further refine the type enforcement rules and the role allow rules. Typically, these constraints are used to restrict changes in user identity or role to certain domains.

(Note that this file does not contain the MLS / MCS constraints as they are in the mls and mcs files described below).

Source Configuration Files

There are two major configuration files (build.conf and modules.conf) that define the policy to be built and are detailed in this section.

Reference Policy Build Options - build.conf

This file defines the policy type to be built that will influence its name and where the source will be located once it is finally installed. It also configures the MCS / MLS sensitivity and category maximum values. An example file content is shown in the Installing and Building the Reference Policy Source section where it is used to install and then build the policy.

Table 2 explains the fields that can be defined within this file, however there are a number of m4 macro parameters that are set up when this file is read by the build process makefiles. These definitions are shown in Table 3 and are also used within the module source files to control how the policy is built with examples shown in the ifdef / ifndef Parameters section.

Option

Type

Comments

OUTPUT_POLICY

Integer

Set the version of the policy created when building a monolithic policy. This option has no effect on modular policy.

TYPE

String

Available options are standard, mls, and mcs. For a type enforcement only system, set standard. This optionally enables multi-level security (MLS) or multi-category security (MCS) features. This option controls enable_mls, and enable_mcs policy blocks.

NAME

String (optional)

Sets the name of the policy; the NAME is used when installing files to e.g., /etc/selinux/NAME and /usr/share/selinux/NAME. If not set, the policy type field (TYPE) is used.

Set the kernel behaviour for handling of permissions defined in the kernel but missing from the policy. The permissions can either be allowed, denied, or the policy loading can be rejected. See the SELinux Filesystem for more details.

DIRECT_INITRC

Boolean (y|n)

If 'y' sysadm will be allowed to directly run init scripts, instead of requiring the run_init tool. This is a build option instead of a tunable since role transitions do not work in conditional policy. This option controls direct_sysadm_daemon policy blocks.

MONOLITHIC

Boolean (y|n)

If 'y' a monolithic policy is built, otherwise a modular policy is built.

UBAC

Boolean (y|n)

If 'y' User Based Access Control policy is built. The default for Red Hat is 'n'. These are defined as constraints in the policy/constraints file. Note Version 1 of the Reference Policy did not have this entry and defaulted to Role Based Access Control.

MLS_SENS

Integer

Set the number of sensitivities in the MLS policy. Ignored on standard and MCS policies.

MLS_CATS

Integer

Set the number of categories in the MLS policy. Ignored on standard and MCS policies.

MCS_CATS

Integer

Set the number of categories in the MCS policy. Ignored on standard and MLS policies.

QUIET

Boolean (y|n)

If 'y' the build system will only display status messages and error messages. This option has no effect on policy.

Table 2: build.conf Entries

m4 Parameter Name in Makefile

From build.conf entry

Comments

enable_mls

TYPE

Set if MLS policy build enabled.

enable_mcs

TYPE

Set if MCS policy build enabled.

enable_ubac

UBAC

Set if UBAC set to 'y'.

mls_num_sens

MLS_SENS

The number of MLS sensitivities configured.

mls_num_cats

MLS_CATS

The number of MLS categories configured.

mcs_num_cats

MCS_CATS

The number of MCS categories configured.

distro_$(DISTRO)

DISTRO

The distro name or blank.

direct_sysadm_daemon

DIRECT_INITRC

If DIRECT_INITRC entry set to 'y'.

hide_broken_symtoms

This is set up in the Makefile and can be used in modules to hide errors with dontaudit rules (or even allow rules).

Table 3: m4 parameters set at build time - These have been extracted from the Reference Policy Makefile file.

Reference Policy Build Options - policy/modules.conf

This file controls what modules are built within the policy with example entries as follows:

The module will be in the base module for a modular policy build (build.conf entry MONOLITHIC = n).

module

The module will be built as a loadable module for a modular policy build. If a monolithic policy is being built (build.conf entry MONOLITHIC = y), then this module will be built into the base module.

off

The module will not be included in any build.

Generally it is up to the policy writer to decide which modules are in the base and those that are loadable, however there are some modules that MUST be in the base module. To highlight this there is a special entry at the start of the modules interface file (.if) that has the entry <required val='true'> as shown below (taken from the kernel.if file):

The modules.conf file will also reflect that a module is required in the base by adding a comment "Required in base" when the make conf target is executed (as all the .if files are checked during this process and the modules.conf file updated).

There are 13 modules in the F-12 reference policy source marked as required and are shown in Table 4.

Layer

Module Name

Comments

system

application

Policy for user executable applications.
All the interface calls start with 'application_'.

system

setrans

Policy for the SELinux MLS/MCS label translation service.
All the interface calls start with 'setrans_'.

kernel

corecommands

Core policy for shells, and generic programs in:
/bin, /sbin, /usr/bin, and /usr/sbin.
The .fc file sets up the labels for these items.
All the interface calls start with 'corecmd_'.

kernel

corenetwork

Policy controlling access to network objects and also contains the initial SIDs for these.

The .if file is large and automatically generated. All the interface calls start with 'corenet_'.

kernel

devices

This module creates the device node concept and provides the policy for many of the device files. Notable exceptions are the mass storage and terminal devices that are covered by other modules (that is a char or block device file, usually in /dev). All types that are used to label device nodes should use the dev_node macro.

Additionally this module controls access to three things:

the device directories containing device nodes.

device nodes as a group

individual access to specific device nodes covered by this module.

All the interface calls start with 'dev_'.

kernel

domain

Contains the core policy for forming and managing domains.

All the interface calls start with 'domain_'.

kernel

files

This module contains basic filesystem types and interfaces and includes:

Contains the policy for kernel threads, proc filesystem, and unlabeled processes and objects. This module has initial SIDs.

All the interface calls start with 'kernel_'.

kernel

mcs

Policy for Multicategory security. The .te file only contains attributes used in MCS policy.

All the interface calls start with 'mcs_'.

kernel

mls

Policy for Multilevel security. The .te file only contains attributes used in MLS policy.

All the interface calls start with 'mls_'.

kernel

selinux

Contains the policy for the kernel SELinux security interface (selinuxfs).

All the interface calls start with 'selinux_'.

kernel

terminal

Contains the policy for terminals.

All the interface calls start with 'term_'.

Table 4: Mandatory modules.conf Entries

Building the modules.conf File

The file can be created by an editor, however it is generally built initially by make conf that will add any additional modules to the file. The file can then be edited to configure the required modules as base, module or off.

Source Installation and Build Make Options

This section explains the various make options available that have been taken from the README file. Table 5 describes the general make targets, Table 6 describes the modular policy make targets and Table 7 describes the monolithic policy make targets.

Make Target

Comments

install-src

Install the policy sources into /etc/selinux/NAME/src/policy, where NAME is defined in the build.conf file. If it is not defined, then TYPE is used instead. If a build.conf does not have the information, then the Makefile will default to the current entry in the /etc/selinux/config file or default to refpolicy. A pre-existing source policy will be moved to /etc/selinux/NAME/src/policy.bak.

conf

Regenerate policy.xml, and update/create modules.conf and booleans.conf. This should be done after adding or removing modules, or after running the bare target. If the configuration files exist, their settings will be preserved. This must be run on policy sources that are checked out from the CVS repository before they can be used.

clean

Delete all temporary files, compiled policies, and file_contexts. Configuration files are left intact.

bare

Do the clean make target and also delete configuration files, web page documentation, and policy.xml.

Compile and package the base module. This is the default target for modular policies.

modules

Compile and package all Reference Policy modules configured to be built as loadable modules.

MODULENAME.pp

Compile and package the MODULENAME Reference Policy module.

all

Compile and package the base module and all Reference Policy modules configured to be built as loadable modules.

install

Compile, package, and install the base module and Reference Policy modules configured to be built as loadable modules.

load

Compile, package, and install the base module and Reference Policy modules configured to be built as loadable modules, then insert them into the module store.

validate

Validate if the configured modules can successfully link and expand.

install-headers

Install the policy headers into /usr/share/selinux/NAME. The headers are sufficient for building a policy module locally, without requiring the complete Reference Policy sources. The build.conf settings for this policy configuration should be set before using this target.

Table 6: Modular Policy Build Make Targets

Make Target

Comments

policy

Compile a policy locally for development and testing. This is the default target for monolithic policies.

install

Compile and install the policy and file contexts.

load

Compile and install the policy and file contexts, then load the policy.

enableaudit

Remove all dontaudit rules from policy.conf.

relabel

Relabel the filesystem.

checklabels

Check the labels on the filesystem, and report when a file would be relabeled, but do not change its label.

restorelabels

Relabel the filesystem and report each file that is relabeled.

Table 7: Monolithic Policy Build Make Targets

Booleans, Global Booleans and Tunable Booleans

The three files booleans.conf, global_booleans and global_tunables are built and used as follows:

booleans.conf

This file is generated / updated by make conf, and contains all the booleans in the policy with their default values. If tunable and global booleans are implemented then these are also included.

This file can also be delivered as a part of the reference policy source as shown in the outline Installing and Building the Reference Policy Source section. This is generally because other default values are used for booleans and not those defined within the modules themselves (i.e. distribution specific booleans). When the make install is executed, then this file will be used to set the default values.

Note that if booleans are updated locally then the policy store will contain a booleans.local file.

In SELinux enabled systems that support the policy store features (modular policies) this file is not installed as /etc/selinux/NAME/booleans.

global_booleans

These are booleans that have been defined in the global_tunables file using the gen_bool macro. They are normally booleans for managing the overall policy and currently consist of the following (where the default values are false):

secure_mode
secure_mode_insmod
secure_mode_policyload

global_tunables

These are booleans that have been defined in module files using the gen_tunable macro and added to the global_tunables file by make conf. The tunable_policy macros are defined in each module where policy statements or interface calls are required. They are booleans for managing specific areas of policy that are global in scope. An example is allow_execstack that will allow all processes running in unconfined_t to make their stacks executable.

Modular Policy Build Structure

This section explains the way a modular policy is constructed, this does not really need to be known but is used to show the files used that can then be investigated if required.

When make all or make load or make install are executed the build.conf and modules.conf files are used to define the policy name and what modules will be built in the base and those as individual loadable modules.

Basically the source modules (.te, .if and .fc) and core flask files are rebuilt in the tmp directory where the reference policy macros[6] in the source modules will be expanded to form actual policy language statements as described in the Policy Language section. Figure 3 shows these temporary files that are used to form the base.conf[7] file during policy generation.

The base.conf file will consist of language statements taken from the module defined as base in the modules.conf file along with the constraints, users etc. that are required to build a complete policy.

The individual loadable modules are built in much the same way as shown in Figure 4.

Base Policy Component Description

Policy Source File Name (relative to ./policy/policy)

./policy/tmp

File Name

The object classes supported by the kernel.

flask/security_classes

pre_te_files.conf

The initial SIDs supported by the kernel.

flask/initial_sids

The object class permissions supported by the kernel.

flask/access_vectors

This is either the expanded mls or mcs file depending on the type of policy being built.

mls or mcs

These are the policy capabilities that can be configured / enabled to support the policy.

policy_capabilities

This area contains all the attribute, bool, type and typealias statements extracted from the *.te and *.if files that form the base module.

modules/*/*.te

modules/*/*.if

all_attrs_types.conf

Contains the global and tunable bools extracted from the conf files.

global_bools.conf

global_tunables.conf

global_bools.conf

Contains the rules extracted from each of the modules .te and .if files defined in the modules.conf file as "base".

base modules

only_te_rules.conf

Contains the expanded users from the users file.

users

all_post.conf

Contains the expanded constraints from the constraints file.

constraints

Contains the default SID labeling extracted from the *.te files.

modules/*/*.te

Contains the fs_use_xattr, fs_use_task, fs_use_trans and genfscon statements extracted from each of the modules .te and .if files defined in the modules.conf file as "base".

modules/*/*.te

modules/*/*.if

Contains the netifcon, nodecon and portcon statements extracted from each of the modules .te and .if files defined in the modules.conf file as "base".

modules/*/*.te

modules/*/*.if

Contains the expanded file context file entries extracted from the *.fc files defined in the modules.conf file as "base".

modules/*/*.fc

base.fc.tmp

Expanded seusers file.

seusers

seusers

These are the commands used to compile, link and load the base policy module:

Figure 3: Base Module Build - This shows the temporary build files used to build the base module "base.conf" as a part of the "make" process. Note that the modules marked as base in modules.conf are built here.

Base Policy Component Description

Policy Source File Name (relative to ./policy/policy)

./policy/tmp

File Name

For each module defined as "module" in the modules.conf configuration file, a source module is produced that has been extracted from the *.te and *.if file for that module.

modules/*/<module_name>.te

modules/*/<module_name>.if

<module_name>.tmp

For each module defined as "module" in the modules.conf configuration file, an object module is produced from executing the checkmodule command shown below.

tmp/<module_name>.tmp

<module_name>.mod

For each module defined as "module" in the modules.conf configuration file, an expanded file context file is built from the <module_name>.fc file.

modules/*/<module_name>.fc

base.fc.tmp

This command is used to compile each module:

checkmodule tmp/<module_name>.tmp -o tmp/<module_name>.mod

Each module is packaged and loaded with the base module using the following commands:

Figure 4: Module Build - This shows the module files and the temporary build files used to build each module as a part of the "make" process (i.e. those modules marked as module in modules.conf).

Creating Additional Layers

One objective of the reference policy is to separate the modules into different layers reflecting their "service" (e.g. kernel, system, app etc.). While it can sometimes be difficult to determine where a particular module should reside, it does help separation, however because the way the build process works, each module must have a unique name.

If a new layer is required, then the following will need to be completed:

Create a new layer directory ./policy/modules/LAYERNAME that reflects the layer's purpose.

In the ./policy/modules/LAYERNAME directory create a metadata.xml file. This is an XML file with a summary tag and optional desc (long description) tag that should describe the purpose of the layer and will be used as a part of the documentation. An example is as follows:

<summary>ABC modules for the XYZ components.</summary>

Installing and Building the Reference Policy Source

This section explains how to install the F-12 reference policy source that is distributed by Red Hat (however the same principle is followed for the source taken directly from the Tresys repository, except that it will not build a compatible policy to that discussed in this section).

Any F-12 policy source rpm will suffice and can be obtained from the http://koji.fedoraproject.org web site, however it is assumed that the source rpm is:

selinux-policy-3.6.32-103.fc12.src.rpm

The objective of this exercise is to show that the policy built from the above source rpm is an exact replica of the targeted policy distributed as header files in the F-12 targeted rpm:

selinux-policy-targeted-3.6.32-103.fc12.noarch.rpm

Note that there is a good overview of rebuilding the source policy at Dan Walsh's site:

The serefpolicy-3.6.32 directory will now contain the source code with the latest patches for this release (3.6.32-103) of the Red Hat Reference Policy and the correct configuration files for a targeted policy.

The ./serefpolicy-3.6.32/build.conf must now be modified to allow the source to be installed in its final location and have the correct parameters set for the build. The entries that need to be updated in the build.conf file are highlighted below[8]:

#
# Policy build options
#
# Policy version
# By default, checkpolicy will create the highest version policy it supports.
# Setting this will override the version. This only has an effect for
# monolithic policies.
#OUTPUT_POLICY = 18
# Policy Type
# standard, mls, mcs. Note Red Hat always build the MCS Policy Type as their “targeted” version.
TYPE = mcs
# Policy Name
# If set, this will be used as the policy name. Otherwise the policy type
# will be used for the name. This entry is also used by the "make install-src" process to copy the source to the:
# /etc/selinux/targeted-103/src/policy directory.
NAME = targeted-103
# Distribution
# Some distributions have portions of policy for programs or configurations
# specific to the distribution. Setting this will enable options for the
# distribution. redhat, gentoo, debian, suse, and rhel4 are current options.
# Fedora users should enable redhat.
DISTRO = redhat
# Unknown Permissions Handling
# The behaviour for handling permissions defined in the kernel but missing from
# the policy. The permissions can either be allowed, denied, or the policy
# loading can be rejected.
# allow, deny, and reject are current options. Red Hat use allow for all
# policies except MLS that uses 'deny'.
UNK_PERMS = allow
# Direct admin init
# Setting this will allow sysadm to directly run init scripts, instead of
# requiring run_init. This is a build option, as role transitions do not work in
# conditional policy.
DIRECT_INITRC = n
# Build monolithic policy. Putting n here will build a loadable module policy.
MONOLITHIC = n
# User-based access control (UBAC)
# Enable UBAC for role separations. Note Red Hat disable UBAC.
UBAC = n
# Number of MLS Sensitivities
# The sensitivities will be s0 to s(MLS_SENS-1). Dominance will be in increasing
# numerical order with s0 being lowest.
MLS_SENS = 16
# Number of MLS Categories. Note Red Hat use 1024 categories for MLS and MCS.
# The categories will be c0 to c(MLS_CATS-1).
MLS_CATS = 1024
# Number of MCS Categories
# The categories will be c0 to c(MLS_CATS-1).
MCS_CATS = 1024
# Set this to y to only display status messages during build.
QUIET = n

The policy source is now in a position to be installed at its default location that will be derived from the NAME = targeted-103 entry and will therefore be located at:

/etc/selinux/targeted-103/src/policy

Building the targeted Policy Type

From the ./serefpolicy-3.6.32 directory run the following command:

make install-src

This will copy the source code to its final location making any directories required.

Once the copy process is complete the policy can be built and the modules loaded into the policy store[9] by running the following commands:

# Go to the source location:
cd /etc/selinux/targeted-103/src/policy

# To ensure a clean source build:
make clean

# Build the policy modules and load into the policy store:
make load

# Finally copy over two files that are not automatically
# managed by the build process. These are held in the
# config/appconfig-mcs directory.
#
cp config/appconfig-mcs/setrans.conf /etc/selinux/targeted-103
# Need to over-write the old version of this file with this one:
cp config/appconfig-mcs/customizable_types /etc/selinux/targeted-103/contexts

The policy will now be built as a targeted policy that will be an exact copy of the policy distributed in the following rpm:

selinux-policy-targeted-3.6.32-103.fc12.noarch.rpm

Checking the Build

Now that the targeted policy has been built, the policy binary file can be compared to the one that is distributed and built by the following rpm:

Note that the binaries would not be an exact comparison due to time stamps etc., therefore the SETools sediffx utility should be run against the two binary policies[10] which should show that they are the same and give the results shown in "Comparing the two "targeted" policies using sediffx" screen shots.

Running with the new Policy

To run the system using the new targeted-103 build edit the /etc/selinux/config file entry to read SELINUXTYPE=targeted-103, and then run the following commands:

touch /.autorelabel
reboot

During reboot, the system will be relabeled and the policy loaded (hopefully with no errors).

Reference Policy Headers

This method of building policy and adding new modules is used for distributions that do not require access to the source code.

Building and Installing the Header Files

To be able to fully build the policy headers from the reference policy source two steps are required:

Ensure the source is installed and configured as described in the Installing and Building the Reference Policy Source section. This is because the make load (or make install) command will package all the modules as defined in the modules.conf file, producing a base.pp and the relevant .pp packages. The build process will then install these files in the /usr/share/selinux/<policy_name> directory.

Execute the make install-headers command that will:

a) Produce a build.conf file that represents the contents of the master build.conf file and place it in the /usr/share/selinux/<policy_name>/include directory.

b) Produce the XML documentation set that reflects the source and place it in the /usr/share/selinux/<policy_name>/include directory.

c) Copy a development Makefile for building from policy headers to the /usr/share/selinux/<policy_name>/include directory.

d) Copy the support macros .spt files to the /usr/share/selinux/<policy_name>/include/support directory.

Using the Header Files

Note that this section describes the standard Reference Policy headers, the F-12 installation is slightly different and described in the Using F-12 Supplied Headers section.

Once the headers are installed as defined above, new modules can be built in any local directory. An example set of module files are located in the reference policy source at /etc/selinux/targeted-103/src/policy/doc and are called example.te, example.if, and example.fc.

During the header build process a Makefile was included in the headers directory. This Makefile can be used to build the example modules by using makes -f option as follows (assuming that the example module files are in the local directory):

make -f <tt>/usr/share/selinux/<policy_name>/include/Makefile</tt>

However there is another Makefile that can be installed in the users home directory ($HOME) that will call the master Makefile. This is located at /etc/selinux/targeted-103/src/policy/doc in the reference policy source and is called Makefile.example. This is shown below (note that it extracts the <policy_name> from the SELinux config file):

Compile and package the modules in the current directory, then insert them into the module store.

refresh

Attempts to reinsert all modules that are currently in the module store from the local and system module packages.

xml

Build a policy.xml from the XML included with the base policy headers and any XML in the modules in the current directory.

Table 9: Header Policy Build Make Targets

Using F-12 Supplied Headers

The F-12 distribution installs the headers in a slightly different manner as Red Hat installs:

The packaged files under the /usr/share/selinux/<policy_name>, these files may be .pp files or .pp.bz2 depending on the version of rpm installed (later ones compressed the packages). They are installed by the selinux-policy-<policy_name>-3.6.32-103.fc12.noarch type rpms.

The development header files are installed in the /usr/share/selinux/devel directory by the selinux-policy-3.6.32-103.fc12.noarch rpm. Red Hat also include an additional application called policygentool that allows users to generate policy by answering various questions. This tool is described in the Fedora 12 SELinux User Guide. The example modules are also in this directory and the Makefile is also slightly different to that used by the Reference Policy source.

The documentation is supplied in the selinux-policy-doc-3.6.32-103.fc12.noarch type rpms and would be installed (for this version), in the /usr/share/doc/selinux-policy-3.6.32/html directory.

Reference Policy Support Macros

This section explains some of the support macros used to build reference policy source modules (see Table 10 for the list). These macros are located at:

Declares sensitivities s0 to s(N-1) with dominance in increasing numeric order with s0 lowest, s(N-1) highest.

gen_levels

Generate levels from s0 to (N-1) with categories c0 to (M-1)

mls_systemlow

Basic level names for system low and high

mls_systemhigh

mcs_systemlow

mcs_systemhigh

mcs_allcats

Allocates all categories

Table 10: Support Macros described in this section

Notes:

The macro calls can be in any configuration file read by the build process and are contained in (for example) the users, mls, mcs and constraints files.

There are four main m4 ifdef parameters used within modules:

enable_mcs - this is used to test if the MCS policy is being built.

enable_mls - this is used to test if the MLS policy is being built.

enable_ubac - this enables the user based access control within the constraints file.

hide_broken_symptoms - this is used to hide errors in modules with dontaudit rules.

These are also mentioned in Table 3 as they are set by the initial build process with examples shown in the ifdef / ifndef Parameters section.

The macro examples in this section have been taken from the reference policy module files and shown in each relevant 'Example Macro' section. The macros are then expanded by the build process to form modules containing the policy language statements and rules in the tmp directory. These files have been extracted and modified for readability, then shown in each relevant 'Expanded Macro' section.

Be aware that spaces between macro names and their parameters are not allowed:

Allowed:

policy_module(ftp, 1.7.0)

Not allowed:

policy_module (ftp, 1.7.0)

Loadable Policy Macros

The loadable policy module support macros are located in the loadable_module.spt file.

policy_module Macro

This macro will add the module Statement to a loadable module, and automatically add a require Statement with pre-defined information for all loadable modules such as the system_r role, kernel classes and permissions, and optionally MCS / MLS information (sensitivity and category statements).

The macro definition is:

policy_module(module_name,version)

Where:

policy_module

The policy_module macro keyword.

module_name

The module identifier that must be unique in the module layers.

version_number

The module version number in M.m.m format (where M = major version number and m = minor version numbers).

The macro is valid in:

Private Policy File (.te)

External Interface File (.if)

File Labeling Policy File (.fc)

Yes

No

No

Example Macro:

# This example is from the modules/services/ftp.te module:
#
policy_module(ftp, 1.7.0)

gen_require Macro

These statements consist of those allowed in the policy language require Statement.

The macro is valid in:

Private Policy File (.te)

External Interface File (.if)

File Labeling Policy File (.fc)

Yes

Yes

No

Example Macro:

# This example is from the modules/services/ftp.te module:
#
gen_require(`type ftp_script_exec_t;')

Expanded Macro:

# This is the expanded macro from the tmp/ftp.tmp file:
#
require {
type ftp_script_exec_t;
}

optional_policy Macro

For use within module files to insert an optional block that will be expanded by the build process only if the modules containing the access or template interface calls that follow are present. If one module is present and the other is not, then the optional statements are not included (need to check).

The macro definition is:

optional_policy(`optional_statements`)

Where:

optional_policy

The optional_policy macro keyword.

optional_statements

These statements consist of those allowed in the policy language optional Statement. However they can also be interface, template or support macro calls.

gen_tunable Macro

This macro defines booleans that are global in scope. The corresponding tunable_policy macro contains the supporting statements allowed or not depending on the value of the boolean. These entries are extracted as a part of the build process (by the make conf target) and added to the global_tunables file where they can then be used to alter the default values for the make load or make install targets.

Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the documentation.

# This is the expanded macro from the tmp/ftp.tmp file:
#
bool allow_ftpd_use_nfs false;

tunable_policy Macro

This macro contains the statements allowed or not depending on the value of the boolean defined by the gen_tunable macro.

The macro definition is:

tunable_policy(`gen_tunable_id`,`tunable_policy_rules`)

Where:

tunable_policy

The tunable_policy macro keyword.

gen_tunable_id

This is the boolean identifier defined by the gen_tunable macro. It is possible to have multiple entries separated by && or

as shown in the example.

tunable_policy_rules

These are the policy rules and statements as defined in the if Statement policy language section.

The macro is valid in:

Private Policy File (.te)

External Interface File (.if)

File Labeling Policy File (.fc)

Yes

Yes

No

Example Macro:

# This example is from the modules/services/ftp.te module
# showing the use of the boolean with the && operator.
#
tunable_policy(`allow_ftpd_use_nfs && allow_ftpd_anon_write',`
fs_manage_nfs_files(ftpd_t)
')

interface Macro

Access interface macros are defined in the interface module file (.if) and form the interface through which other modules can call on the modules services (as shown in The Resulting Code diagram and described in the Module Expansion section.

Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the documentation.

The macro definition is:

interface(`name`,`interface_rules`)

Where:

interface

The interface macro keyword.

name

The interface identifier that should be named to reflect the module identifier and its purpose.

interface_rules

This can consist of the support macros, policy language statements or other interface calls as required to provide the service.

template Macro

A template interface is used to help create a domain and set up the appropriate rules and statements to run an application / process. The basic idea is to set up an application in a domain that is suitable for the defined SELinux user and role to access but not others. Should a different user / role need to access the same application, another domain would be allocated (these are known as "derived domains" as the domain name is derived from caller information).

The application template shown in the example below is for openoffice.org where the domain being set up to run the application is based on the SELinux user xguest (parameter $1) therefore a domain type is initialised called xguest_openoffice_t, this is then added to the user domain attribute xguest_usertype (parameter $2). Finally the role xguest_r (parameter $3) is allowed access to the domain type xguest_openoffice_t. If a different user / role required access to openoffice.org, then by passing different parameters (i.e. user_u), a different domain would be set up.

The main differences between an application interface and a template interface are:

An access interface is called by other modules to perform a service.

A template interface allows an application to be run in a domain based on user / role information to isolate different instances.

Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the documentation.

The macro definition is:

template(`name`,`template_rules`)

Where:

template

The template macro keyword.

name

The template identifier that should be named to reflect the module identifier and its purpose. By convention the last component is _template (e.g. ftp_per_role_template).

template_rules

This can consist of the support macros, policy language statements or interface calls as required to provide the service.

Miscellaneous Macros

gen_context Macro

This macro is used to generate a valid security context and can be used in any of the module files. Its most general use is in the .fc file where it is used to set the files security context.

The macro definition is:

gen_context(context[,mls | mcs])

Where:

gen_context

The gen_context macro keyword.

context

The security context to be generated. This can include macros that are relevant to a context as shown in the example below.

mcs

MLS or MCS labels if enabled in the policy.

The macro is valid in:

Private Policy File (.te)

External Interface File (.if)

File Labeling Policy File (.fc)

Yes

Yes

Yes

Example Macro:

# This example shows gen_context being used to generate a
# security context for the security initial sid in the
# selinux.te module:
sid security gen_context(system_u:object_r:security_t:mls_systemhigh)

Expanded Macro:

# This is the expanded entry built into the base.conf source
# file for an MLS policy:
sid security system_u:object_r:security_t:s15:c0.c255

Example File Context .fc file:

# This is from the modules/apps/gnome.fc file. Note that the
# HOME_DIR and USER parameters will be entered during
# the file_contexts.homedirs file build.
#
HOME_DIR/.gnome2(/.*)?gen_context(system_u:object_r:gnome_home_t,s0)
HOME_DIR/\.config/gtk-.*gen_context(system_u:object_r:gnome_home_t,s0)
HOME_DIR/\.gconf(d)?(/.*)?gen_context(system_u:object_r:gconf_home_t,s0)
HOME_DIR/\.local.*gen_context(system_u:object_r:gconf_home_t,s0)
/tmp/gconfd-USER/.*--gen_context(system_u:object_r:gconf_tmp_t,s0)
HOME_DIR/.pulse(/.*)?gen_context(system_u:object_r:gnome_home_t,s0)

Expanded File Context .fc file:

# The resulting expanded tmp/gnome.mod.fc file. This will be
# concatenated with the main file_contexts file during the
# policy build process.
#
HOME_DIR/.gnome2(/.*)?system_u:object_r:gnome_home_t:s0
HOME_DIR/\.config/gtk-.*system_u:object_r:gnome_home_t:s0
HOME_DIR/\.gconf(d)?(/.*)?system_u:object_r:gconf_home_t:s0
HOME_DIR/\.local.*system_u:object_r:gconf_home_t:s0
/tmp/gconfd-USER/.*--system_u:object_r:gconf_tmp_t:s0
HOME_DIR/.pulse(/.*)?system_u:object_r:gnome_home_t:s0

gen_bool Macro

Use the boolean in the module files with an if Statement as shown in the example.

Note that the comments shown in the example MUST be present as they are used to describe the function and are extracted for the documentation.

The macro definition is:

gen_bool(name,default_value)

Where:

gen_bool

The gen_bool macro keyword.

name

The boolean identifier.

default_value

The value true or false.

The macro is only valid in in the global_booleans file but the boolean declared can be used in the following module types:

Private Policy File (.te)

External Interface File (.if)

File Labeling Policy File (.fc)

Yes

Yes

No

Example Macro (in global_booleans):

# This example is from the global_booleans file where the bool
# is declared. The comments must be present as it is used to
# generate the documentation.
#
## <desc>
## <p>
## Disable transitions to insmod.
## </p>
## </desc>gen_bool(secure_mode_insmod,false)
# Example usage from the system/modutils.te module:
#
if( ! secure_mode_insmod ) {
kernel_domtrans_to(insmod_t,insmod_exec_t)
}

MLS and MCS Macros

These macros are in the mls_mcs_macros.spt file.

gen_cats Macro

This macro will generate a category Statement for each category defined. These are then used in the base.conf / policy.conf source file and also inserted into each module by the policy_module Macro. The policy/policy/mcs and mls configuration files are the only files that contain this macro in the current reference policy.

The macro definition is:

gen_cats(mcs_num_cats | mls_num_cats)

Where:

gen_cats

The gen_cats macro keyword.

mcs_num_cats

mls_num_cats

These are the maximum number of categories that have been extracted from the build.conf file MCS_CATS or MLS_CATS entries and set as m4 parameters.

The macro is valid in:

Private Policy File (.te)

External Interface File (.if)

File Labeling Policy File (.fc)

na

na

na

Example Macro:

# This example is from the policy/policy/mls configuration file.
#
gen_cats(mls_num_cats)

gen_sens Macro

This macro will generate a sensitivity Statement for each sensitivity defined. These are then used in the base.conf / policy.conf source file and also inserted into each module by the policy_module Macro. The policy/policy/mcs and mls configuration files are the only files that contain this macro in the current reference policy (note that the mcs file has gen_sens(1) as only one sensitivity is required).

The macro definition is:

gen_sens(mls_num_sens)

Where:

gen_sens

The gen_sens macro keyword.

mls_num_sens

These are the maximum number of sensitivities that have been extracted from the build.conf file MLS_SENS entries and set as an m4 parameter.

The macro is valid in:

Private Policy File (.te)

External Interface File (.if)

File Labeling Policy File (.fc)

na

na

na

Example Macro:

# This example is from the policy/policy/mls configuration file.
#
gen_cats(mls_num_sens)

gen_levels Macro

This macro will generate a level Statement for each level defined. These are then used in the base.conf / policy.conf source file. The policy/policy/mcs and mls configuration files are the only files that contain this macro in the current reference policy.

The macro definition is:

gen_levels(mls_num_sens,mls_num_cats)

Where:

gen_levels

The gen_levels macro keyword.

mls_num_sens

This is the parameter that defines the number of sensitivities to generate. The MCS policy is set to "1".

mls_num_cats

mcs_num_cats

This is the parameter that defines the number of categories to generate.

The macro is valid in:

Private Policy File (.te)

External Interface File (.if)

File Labeling Policy File (.fc)

na

na

na

Example Macro:

# This example is from the policy/policy/mls configuration file.
#
gen_levels(mls_num_sens,mls_num_cats)

Expanded Macro:

# This example has been extracted from the base.conf source
# file. Note that the all categories are allocated to each
# sensitivity.
level s0:c0.c1023;
level s1:c0.c1023;
...
level s15:c0.c1023;

enable_ubac

This is used within the ./policy/constraints configuration file to set up various attributes to support user based access control (UBAC). These attributes are then used within the various modules that want to support UBAC. This support was added in version 2 of the Referefence Policy.

The orginal method (role based access control, or RBAC) is the default for F-12 (ubac = n). The parameter is set up by the Makefile with information taken from the build.conf file at the start of the build process (ubac = y | ubac = n).

# This example is from the modules/system/userdomain.te module.
#
ifdef(`direct_sysadm_daemon',`
domain_system_change_exemption($1_t)
')

Module Expansion Process

The objective of this section is to show how the modules are expanded by the reference policy build process to form files that can then be compiled and then loaded into the policy store by using the make MODULENAME.pp target.

The files shown are those produced by the build process using the ada policy modules from the Reference Policy source tree (ada.te, ada.if and ada.fc) that are shown in the Reference Policy Module Files section.

The initial build process will build the source text files in the policy/tmp directory as ada.tmp and ada.mod.fc (that are basically build equivalent ada.conf and ada.fc formatted files). The basic steps are shown in The make ada sequence of events diagram, and the resulting expanded code shown in The Resulting Code diagram. The actual module expansion is left to the reader to investigate.

↑The base.conf gets built for modular policies and a policy.conf file gets built for a monolithic policy.

↑The README file in this directory contains helpful information on installation of the source, headers, documentation etc. The only point the README will not cover are the Red Hat specific configuration files that need to be copied over as shown in Table 8.

↑Note that the term "load" is not loading the policy as the active policy, but just building the base policy + the modules and installing them ready to be activated if required

↑Be aware that comparing these two policies on a low specification machine will take hours. It is best to select a few items for comparison first.