Building a Local Policy Module

The following section uses an actual example to demonstrate building a local policy module to address an issue with the current policy. This issue involves the ypbind init script, which executes the setsebool command, which in turn tries to use the terminal. This is generating the following denial:

type=AVC msg=audit(1164222416.269:22): avc:  denied  { use } for  pid=1940 comm="setsebool" name="0" dev=devpts ino=2 \
 scontext=system_u:system_r:semanage_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=fd

Even though everything still works correctly (that is, it is not preventing any applications form running as intended), it does interrupt the normal work flow of the user. Creating a local policy module addresses this issue.

Using audit2allow to Build a Local Policy Module

The audit2allow utility now has the ability to build policy modules. Use the following command to build a policy module based on specific contents of the audit.log file:

ausearch -m AVC --comm setsebool | audit2allow -M mysemanage

The audit2allow utility has built a type enforcement file (mysemanage.te). It then executed the checkmodule command to compile a module file (mysemanage.mod). Lastly, it uses the semodule_package command to create a policy package (mysemanage.pp). The semodule_package command combines different policy files (usually just the module and potentially a file context file) into a policy package.

Analyzing the Type Enforcement (TE) File

Use the cat command to inspect the contents of the TE file:

~]# cat mysemanag.te
module mysemanage 1.0;
require {
 class fd use;
 type init_t;
 type semanage_t;
 role system_r;
};
allow semanage_t init_t:fd use;

The TE file is comprised of three sections. The first section is the module command, which identifies the module name and version. The module name must be unique. If you create an semanage module using the name of a pre-existing module, the system would try to replace the existing module package with the newly-created version. The last part of the module line is the version. semodule can update module packages and checks the update version against the currently installed version.

The next block of the TE file is the require block. This informs the policy loader which types, classes and roles are required in the system policy before this module can be installed. If any of these fields are undefined, the semodule command will fail.

Lastly are the allow rules. In this example, you could modify this line to dontaudit, because semodule does not need to access the file descriptor.

Loading the Policy Package

The last step in the process of creating a local policy module is to load the policy package into the kernel.

Use the semodule command to load the policy package:

~]# semodule -i mysemanage.pp

This command recompiles the policy file and regenerates the file context file. The changes are permanent and will survive a reboot. You can also copy the policy package file (mysemanage.pp) to other machines and install it using semodule.

The audit2allow command outputs the commands it executed to create the policy package so that you can edit the TE file. This means you can add new rules as required or change the allow rule to dontaudit. You could then recompile and repackage the policy package to be installed again.

There is no limit to the number of policy packages, so you could create one for each local modification you want to make. Alternatively, you could continue to edit a single package, but you need to ensure that the "require" statements match all of the allow rules.