Using SELinux on an ICE-Linux CMS

Writing Policy from Violations

RHEL 5 introduced a mechanism, named policy modules, to change SELinux policy while the system is

running. A module is just a modification to the existing policy. To build an SELinux policy module from

violations, begin with the AVCs associated with them. They can be found in the sealert GUI

beneath the descriptive text for each log entry or in one of two log files: the /var/log/messages

file or the /var/log/audit/audit.log file if you're using auditd. It is beyond the scope of this

document to explain the syntax of the AVCs. HP recommends you consult the SELinux Troubleshooter

descriptions to understand the nature of each violation. An AVC message resembles the following:

avc: denied { getattr } for comm="rsync" dev=dm-0 egid=99 euid=99

exe="/usr/bin/rsync" exit=0 fsgid=99 fsuid=99 gid=99 items=0 path="/bin"

pid=18167 scontext=system_u:system_r:rsync_t:s0 sgid=99

subj=system_u:system_r:rsync_t:s0 suid=99 tclass=dir

tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=99

A program called audit2allow takes these AVCs on standard input to generate policy modules that

can be loaded and that will allow the problematic actions to proceed. The typical usage is shown

here:

# audit2allow -M local < myfile.txt

The -M local option specifies that the audit2allow command generate a policy module named

local. In this example, myfile.txt is a plain text file that contains any number of AVCs, one per

line. This file must be created by hand first, and the AVCs in it should only be the violations that are to

be allowed in the resultant policy module. Notice that it is directed to the audit2allow command's

standard input. This command creates two files in the working directory, local.pp and local.te.

The names of the files are taken from the parameters to the -M option. Note that audit2allow will

overwrite existing files with the same name, so use caution. The first file is the binary policy module

that can be loaded into the kernel. The second file is the policy module source file, which can be used

by the checkmodule command to generate binary policy modules as well. This is covered later in

this section.

Another, more comprehensive, but risky method is using the AVC logs provided by the kernel or

auditd in either of these two formats:

# audit2allow -M local < /var/log/messages

# audit2allow -M local < /var/log/audit/audit.log

This command takes all the AVCs in /var/log/messages or /var/log/audit/audit.log files

and generates a policy that allows all the offending actions to proceed. This method is

recommended only if it can be certain that all the violations in the entire list are

actions that should be allowed. These log files can become quite large and comprehensive,

and may even be rotated, so user discretion is advised.

After running the audit2allow command, examine the .te file just created. Within it, in order of

appearance, are: the module command, require block, and allow rules. The module command

defines the module name and version, which should match the name given when audit2allow was

run to generate this file. Next is the require block, which defines types, classes, and roles that must be

present in the system policy before loading the module. They are defined in the Reference policy

provided with RHEL 5. Last is the allow rules; they should correlate with the AVC messages used

earlier to generate the policy. Double-check that everything to be allowed in the policy module is

indeed what you want to allow.