Section 12.5. Build Options for Reference Policy

12.5. Build Options for Reference Policy

The reference policy was designed to be customizable without having to understand all the details of the policy. The primary build targets for reference policy are all identical in name and function to the example policy. For example, the Makefile targets, policy, policy.conf, relabel, and load all produce the same results as we discussed in Chapter 11 for the example policy.

Two policy build configuration files that are unique to reference policy are the build.conf and the modules.conf.

12.5.1. The build.conf File

We discussed some of the options controlled by the build.conf earlier in this chapter. The first option we want to discuss in this file is the policy type. One of the goals of the reference policy is the ability to create differing types of policies from the same source tree. This build option controls what type of policy is built. It is specified with the TYPE option in build.conf. As noted throughout this chapter, we can build either a targeted or a strict policy. For example, if we wanted to build a strict policy, we would use the following value for this option:

TYPE = strict

For a targeted policy, we would set the option to targeted instead. In addition, we can enable the optional MLS features in one of two ways, as a typical MLS policy (strict-mls or targeted-mls) or as the MCS configuration (strict-mcs or targeted-mcs). These six values (strict, targeted, strict-mls, targeted-mls, strict-mcs, and targeted-mcs) are the only currently supported policy types for reference policy.

Another option in build.conf is the policy name, which is specified with the NAME option. This is a nice feature in reference policy that allows us to name the policy something other than its policy type. The name is used to determine the install directory for the policy in /etc/selinux/. For example, take the policy name as provided by default from the reference policy project:

NAME = refpolicy

In this case, when we install the policy, the install directory for the policy is /etc/selinux/refpolicy/. If no value is provided, the policy type name will be used. For example, assume our build.conf file has these two lines:

TYPE = targeted NAME =

Our install directory would then be /etc/selinux/targeted/. This is fine if you want to use the reference policy in place of your default targeted policy. If you are trying to experiment with the reference policy, however, you do not necessarily want to overwrite your current, system-provided targeted policy.

Another option of interest is the distribution tunable, DISTRO. As discussed in the sidebar on page 184, the reference policy supports a distribution-specific tunable for distribution-specific policy variations. For example, for FC and RHEL systems, this option would currently be set as follows:

DISTRO = redhat

The final build.conf option we want to discuss is whether the policy is a monolithic policy. This option is controlled by the MONOLITHIC option. If we are building a monolithic policy (that is, one entire kernel binary policy as is common today), we would set this option as follows:

MONOLITHIC=y

Otherwise, we would set this option like this:

MONOLITHIC=n

An n indicates that we want to support loadable modules and will be building both the base module and the loadable modules. Which modules are part of the base module, and which are loadable, is controlled by the modules.conf, which we discuss next.

12.5.2. The modules.conf File

The modules.conf file controls which modules we include in our policy build and in what form. We can find this file in policy/modules.conf. If the file is not present, you can create it with the make conf command from the policy root directory. This command creates a modules.conf file with an entry for all modules in the policy/modules/ directory. If the modules.conf file already exists, make conf appends any new modules to the files (that is, those not already included in the file) without changing any settings for the existing modules. Thus, when we add new modules, we run make conf and then modify the settings for the new modules in modules.conf.

An entry in modules.conf looks like this:

# Layer: admin1 # Module: netutils # # Network analysis utilities # netutils = module

This is the entry that is generated from the netutils module discussed previously. The comment lines (proceeded by #) are generated from the module for informational purposes. The layer comment comes from the name of the directory where the module files are located, the module name comment comes from the root names of the module files, and the description comment comes from the module summary description in the top of the module .if file.

The only effective line is the netutils = module line, which tells the policy build tools how to treat this module during the build process. A module can be set to one of three values. Depending on the type of build (monolithic or loadable module), these values determine how and if the module is built. Possible values for a module are as follows:

base	For a monolithic policy build, all modules marked as base will be included in the policy. For loadable module policy build, all modules marked as base will be included in the base module.
module	For a monolithic policy build, all modules marked as module will be treated the same as base and will be included in the policy. For a loadable module policy build, all modules marked as module will be built as loadable modules.
off	For both monolithic and loadable module builds, all modules marked as off will not be built in any fashion.

All modules that are in the policy/module/ directory that are not listed in the modules.conf file, or which are listed but do not have a value, will not be built in any fashion (as if they were marked as off).

When creating or updating the modules.conf file with the make conf command, all modules will be marked as module unless the module is marked as required within the module interface (.if) file. For example, here is the header for the kernel module .if file. The kernel module is always required:

## <summary> ##    Policy for kernel threads, proc filesystem, and ##    unlabeled processes and objects. ## </summary> ## <required val="true"> ##    This module has initial SIDs. ## </required>

The block that starts with <required val="true"> indicates that this module is required along with a comment explaining why. For all such modules, the default value from modules.conf will be base, ensuring that the module is always included in a monolithic policy or as part as the base module for a loadable module policy. Thus, when we generate the modules.conf file, the kernel module block looks something like this:

# Layer: kernel # Module: kernel # Required in base # # Policy for kernel threads, proc filesystem, and # unlabeled processes and objects. # kernel = base

As you can see, in addition to setting the default value to base, there is also an extra comment ("Required in base") that notes for future reference that this module should always be base.