NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Chapter 7. Compiling
The commands and steps covered in this chapter may render your
system inoperable or unable to be supported.
Nothing in this chapter should be performed on a production
system without having been thoroughly tested in a development or
sandbox environment first.
If you are going to compile and install a custom policy, be
prepared to take the actions you need to safeguard your data and
installation. Proper backup procedures, change-reversal plans, and
an informed methodology are key to your success.
This chapter covers the considerations and methods for compiling
SELinux policy. Following instructions on compiling SELinux policy,
this chapter presents some reference information and
Policy is usually compiled to enable a customization to take
effect on your system. You may also compile policy under
development, such as when working on writing a new policy or
When you install a new policy, you must eventually reboot to
test that it works during system start-up. If the policy change is
significant enough, such as installing an entirely new policy, you
need to reboot to ensure all applications are running in the right
context for the loaded policy. This is similar to any major
configuration change under Linux; you want to be sure it works
properly from system start-up on at least one production-equivalent
Policy updates from Red Hat should not require a reboot after
installation. If a reboot were required, that fact would be clearly
noted in the package advisory.
A reboot is required when the policy change is significantly
different. For example, switching from the targeted to the strict
policy requires a reboot. Ordinary policy updates do not.
To compile SELinux policy:
Compiling the SELinux Policy
Policy compiles if there are new or changed files in certain
locations in the source tree. Those files must have a later
timestamp than policy.conf. If you want
to compile the policy but cannot because of the timestamp, you can
force a compile.
To compile the policy, run make <make_policy_target>.
If you need to force a policy build, run make -W <users>
<load>. The target can be
any from the Makefile.
The -W option tells make to act as if the command touch had been run on the file users. This virtual update of the timestamp is only
from the perspective of make. It triggers
the Makefile to build and load the policy
because the virtual change to the users
file gives it a later timestamp than the policy.conf file.
In order to compile the policy, you need to install the policy
source package, selinux-policy-targeted-sources-<version>.
The Significant Policy make Targets list that follows discusses
important make targets in the SELinux
policy sources. The Makefile itself has
more options that you can explore yourself.
Significant Policy make
Compiles, installs, and fully loads the policy into memory.
This runs load_policy and installs
$SELINUX_POLICY/policy.<XY> and /etc/selinux/targeted/contexts/files/file_contexts.
When the policy gets loaded, the file $SELINUX_SRC/tmp/load is created. The Makefile does not compile the policy as long as
nothing has changed in the policy source tree since the creation
time on the file policy.conf.
Compiles, installs, and loads or reloads the policy. Reloading
lets you load the policy in runtime even if the file $SELINUX_SRC/tmp/load is present and newer than the
last changes in policy source.
Only compiles the policy, putting the resulting binary policy
file into $SELINUX_SRC/policy.<XY>. It also creates a new
policy.conf file, file_contexts/file_contexts, and so forth. This is
useful for developing policy that you intend to deploy on another
Relabels the file system using the policy sources, based on the
file $SELINUX_SRC/file_contexts/file_contexts. As
explained in Section 5.2.2
Relabel a File System, this is not the recommended method for relabeling a file
Enables auditing on all of the policy rules that are marked
dontaudit. The enableaudit target changes the dontaudit rules in policy.conf, which is then loaded.
This is useful for troubleshooting if you are getting SELinux
denials that are not generating audit messages. This is usually
discovered by testing with setenforce 0 to
see if the operation is then allowed.
When enabled, the number of denial messages may be very large.
You return to a dontaudit-state
by running make clean and then make load in $SELINUX_SRC/.
The Makefile makes some decisions
based on the timestamps of the two policy files $SELINUX_SRC/policy.conf, $SELINUX_SRC/policy.<XY>, and the file $SELINUX_SRC/tmp/load/. Because of this you may run
into tricky behavior.
The Makefile will only rebuild
policy.conf if there are newer policy
files in the source tree. Two behaviors arise from this:
If you move a TE file into the source tree that has a timestamp
older than the policy.conf, the
Makefile does not rebuild policy.conf.
If you move a TE file so that it is no longer in the build path,
in particular $SELINUX_SRC/domains/misc/,
the Makefile does not necessarily
recognize the change.
When this occurs, make load will
validate the policy and touch tmp/load,
but not compile the policy. You can force the compile with
make -W users load.
The make load command compares the
timestamp on tmp/load and the binary
policy file in $SELINUX_SRC/. This file,
policy.<XY>, is created in the policy
source directory by the command make
policy. If the binary policy file is newer than the file
tmp/load, the policy is loaded.
For example, you write a local.te
custom policy file, run tests on it, then remove the file from the
source tree. With no new files in the policy source tree, the
Makefile does not reload the policy. This
is because the Makefile is only looking
for new files in the source tree. You must run make -W users load, which compiles, installs, and
loads the policy. This returns you to an uncustomized state.
Later you decide to use the custom policy again. You retrieve
the file from the unused policy source location, moving it back to
where it will compile into the policy. However, running make load or make reload
has no effect. This is because the file local.te is not a new file, it continues to have
the original creation timestamp on it. In order to keep the
accurate timestamp on the file, rather than using touch you can again use make -W