Minor Customizations Of The Existing Policy - Red Hat ENTERPRISE LINUX 4 - SELINUX GUIDE Manual

96

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
policy. It assumes that you have one or more
Tip
Put local policy changes in
$SELINUX_SRC/file_contexts/misc/local.fc
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
$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
where the content came from, that is a decision made in the
$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
You must look through the rules generated by
application generates an SELinux denial asking for read and write permission to
generated by
audit2allow
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
1. Be sure you are in the policy source directory:
cd $SELINUX_SRC/
2. If you have an existing file at
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
audit2allow
$SELINUX_SRC/domains/misc/local.te
.
is all of the various source files concatenated together. It does not need to know
generates a rule does not make it a good or secure rule.
out of the audit log would allow that permission. You need to understand
audit2allow
$SELINUX_SRC/domains/misc/local.te
Chapter 8. Customizing and Writing Policy
to add minor custom rules to the existing
messages in
avc: denied
. Your files are picked up on compile.
Makefile
for a sanity check. For example, an
audit2allow
.
$AUDIT_LOG
, and file context information in
or new files within
local.te
. The files and directories in
/etc/passwd
, make a backup before
. A rule