96

Chapter 8. Customizing and Writing Policy

8.2. Minor Customizations of the Existing Policy

You may find it useful to resolve SELinux denials by using new policy rules to allow the behavior.

The ramifications on security are impossible to predict. At the worst, you are back to standard Linux

security. Your policy changes may be enough to effectively disable the confinement for one or more

parts of a targeted daemon policy.

You must take these considerations into account when adjusting the policy. You can use apol to ana 

lyze the transitions and TE rules, looking for where your policy changes weaken security. For more

information about working with apol, read Section 6.3 Using apol for Policy Analysis.

This procedure takes you through using

audit2allow

to add minor custom rules to the existing

policy. It assumes that you have one or more

avc: denied

messages in

$AUDIT_LOG

.

Tip

Put local policy changes in $SELINUX_SRC/domains/misc/local.te, and file context information in

$SELINUX_SRC/file_contexts/misc/local.fc. Your files are picked up on compile.

Separating your local customizations from the main source is akin to maintaining a set of patches to

pristine source code. When you update the policy source, your changes won't be clobbered or at risk.

If you package your own policy, follow a similar methodology. Use the maintained, upstream

source for either the supported targeted or the unsupported strict policy. You can rebuild the

policy packages, having your changes be in standalone files such as local.te or new files within

$SELINUX_SRC/domains/program/.

If you change the existing TE files, you have to merge the patches with each new policy. Remember

that policy.conf is all of the various source files concatenated together. It does not need to know

where the content came from, that is a decision made in the Makefile. The files and directories in

$SELINUX_SRC/ are a convenience for the policy writer. Following the methods prescribed by the

SELinux developers helps you in your policy writing efforts.

Warning

Just because audit2allow generates a rule does not make it a good or secure rule.

You must look through the rules generated by audit2allow for a sanity check. For example, an

application generates an SELinux denial asking for read and write permission to /etc/passwd. A rule

generated by audit2allow out of the audit log would allow that permission. You need to understand

the underlying application and decide if it should have those permissions.

This is one of the ways SELinux can help find flaws in applications, where excessive and unnecessary

levels of access are attempted.

Adding Rules to the Policy Using

audit2allow

1. Be sure you are in the policy source directory:

cd $SELINUX_SRC/

2. If you have an existing file at

$SELINUX_SRC/domains/misc/local.te

, make a backup before

proceeding with the rule creation:

# The directory domains/unused is ignored during the

# policy build and is a safe place for archiving.

cp domains/misc/local.te domains/unused/local.te.backup