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






footer




 

 

 

 

 Home | About Us | Network | Services | Support | FAQ | Control Panel | Order Online | Sitemap | Contact

adult web hosting

 

Our partners: PHP: Hypertext Preprocessor Best Web Hosting Java Web Hosting Inexpensive Web Hosting  Jsp Web Hosting

Cheapest Web Hosting Jsp Hosting Cheap Hosting

Visionwebhosting.net Business web hosting division of Web Design Plus. All rights reserved