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 analyze
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
-
Be sure you are in the policy source directory:
-
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
|
-
Tell audit2allow to look in dmesg for denial messages, only since the last
load_policy ran, and write that to
domains/misc/local.te:
audit2allow -d -l -o domains/misc/local.te
|
Look in local.te to be sure you don't
have any duplicate rules. This is one reason for having audit2allow generate rules since the last load_policy, to keep from creating duplicates.
Once you have a complete set of working rules, you may want to
look for ways to rewrite and simplify the rules. One way to do this
is to have audit2allow run one final time
against the entire set of denial messages. It looks for ways to
consolidate rules into single lines:
# For example, two passes of audit2allow yield these rules:
allow httpd_t user_home_t:dir getattr;
allow httpd_t user_home_t:dir search;
# Looking at all of denials in $AUDIT_LOG
# may reveal some consolidation of rules, for example:
audit2allow -d -o domains/misc/consolidated_local.te
grep "user_home_t:dir" domains/misc/consolidated_local.te
allow httpd_t user_home_t:dir { getattr search };
|
-
Test your policy. Run make load and try
your previously denied operation(s).
-
At this point you may need to do multiple iterations of these
steps. Each additional rule allows the operation to get one step
further. You use the subsequent denial to write the next rule, and
the process continues.
After multiple iterations, you have a set of rules. Now you want
to analyze the rules to be sure they follow the principle of least
privilege. This is where policy analysis with apol is useful, as described in Section 6.3 Using apol for Policy Analysis.
To make your policy more elegant and efficient, look for macros
that provide you the permissions created by your new rules. You can
then scrap one or more rules in favor of a macro, which simplifies
code reuse. Ideally, your rules benefit from bug fixes and
enhancements to the entire policy because your rules build on the
policy as a privately maintained set of rules, relying upon the
overall structure of the parent policy.
For example, you are running the targeted policy on a newly
installed server that is using your in-house, custom-configured
syslog-ng instead of sysklogd. You find that the policy for syslogd does not cover all of the non-standard
logging operations that you perform. Some of the additional
operational requirements for your syslog-ng implementation are to open non-standard
files and UDP and TCP ports, as well as call non-standard
routines.
The following are a sampling of the avc: denied messages you have received:
Jan 10 04:02:17 example kernel: audit(1009218137.102:0): \
avc: denied { write } for pid=6109 exe=/sbin/syslog-ng \
name=kmsg dev=proc ino=-268435446 \
scontext=system_u:system_r:syslogd_t \
tcontext=system_u:object_r:proc_kmsg_t tclass=file
Jan 10 04:02:17 example kernel: audit(1009218137.105:0): \
avc: denied { read } for pid=16202 exe=/bin/bash name=mtab \
dev=dm-0 ino=7146016 scontext=system_u:system_r:syslogd_t \
tcontext=system_u:object_r:etc_runtime_t tclass=file
...
Jan 10 16:20:35 example kernel: audit(1009284205.210:0): \
avc: denied { chown } for pid=6109 exe=/sbin/syslog-ng \
capability=0 scontext=system_u:system_r:syslogd_t \
tcontext=system_u:system_r:syslogd_t tclass=capability
Jan 10 16:20:35 example kernel: audit(1009284205.210:0): \
avc: denied { fowner } for pid=6109 exe=/sbin/syslog-ng \
capability=3 scontext=system_u:system_r:syslogd_t \
tcontext=system_u:system_r:syslogd_t tclass=capability
Jan 10 16:20:35 example kernel: audit(1009284205.210:0): \
avc: denied { fsetid } for pid=6109 exe=/sbin/syslog-ng \
capability=4 scontext=system_u:system_r:syslogd_t \
tcontext=system_u:system_r:syslogd_t tclass=capability
...
Jan 10 16:20:35 example kernel: audit(1009284205.422:0): \
avc: denied { search } for pid=1411 exe=/bin/bash \
name=sbin dev=dm-0 ino=7356417 \
scontext=system_u:system_r:syslogd_t \
tcontext=system_u:object_r:sbin_t tclass=dir
Jan 10 16:20:35 example kernel: audit(1009284205.422:0): \
avc: denied { getattr } for pid=1411 exe=/bin/bash \
path=/bin/bash dev=dm-0 ino=1245248 \
scontext=system_u:system_r:syslogd_t \
tcontext=system_u:object_r:shell_exec_t tclass=file
Jan 10 16:20:35 example kernel: audit(1009284205.423:0): \
avc: denied { getattr } for pid=1411 exe=/bin/bash \
path=/bin/rm dev=dm-0 ino=1245243 \
scontext=system_u:system_r:syslogd_t \
tcontext=system_u:object_r:bin_t tclass=file
Jan 10 16:20:35 example kernel: audit(1009284205.423:0): \
avc: denied { execute_no_trans } for pid=1411 \
exe=/bin/bash path=/bin/rm dev=dm-0 ino=1245243 \
scontext=system_u:system_r:syslogd_t \
tcontext=system_u:object_r:bin_t tclass=file
Jan 10 16:20:35 example kernel: audit(1009284205.423:0): \
avc: denied { read } for pid=1411 exe=/bin/bash \
path=/bin/rm dev=dm-0 ino=1245243 \
scontext=system_u:system_r:syslogd_t \
tcontext=system_u:object_r:bin_t tclass=file
|
Running all of the audit messages through audit2allow generates a set of rules:
cd /etc/selinux/targeted/src/policy/domains/misc/
audit2allow -i /var/log/messages -o ./local.te
cat local.te
allow syslogd_t bin_t:dir search;
allow syslogd_t bin_t:file { execute execute_no_trans getattr \
read };
allow syslogd_t bin_t:lnk_file read;
allow syslogd_t etc_runtime_t:file { getattr read };
allow syslogd_t proc_kmsg_t:file write;
allow syslogd_t proc_t:file { getattr read };
allow syslogd_t sbin_t:dir search;
allow syslogd_t shell_exec_t:file { execute execute_no_trans \
getattr read };
allow syslogd_t self:capability { chown fowner fsetid sys_admin };
allow syslogd_t usr_t:dir { add_name remove_name write };
allow syslogd_t usr_t:file { append create getattr read setattr \
unlink write };
|
Looking at the rules, you can see that there are two for
execution permissions, and some other rules that are associated by
having the same object, bin_t.
There is also a permission to search directories of the type
sbin_t, but no execution
permissions.
From your reading of the available macros in $SELINUX_SRC/macros/, you know that can_exec() provides a common set of
permissions for domains wishing to execute certain file types. This
includes permissions that are likely to arise once the first set of
basic rules are used. For example, after audit2allow generates a rule giving read permission
to a process, the process often wants getattr permission. The can_exec() macro includes the permission
rx_file_perms, which grants a
common set of read and execute permissions to a file. Now you can
make this substitution:
# these related rules ...
allow syslogd_t bin_t:dir search;
allow syslogd_t bin_t:file { execute execute_no_trans getattr \
read };
allow syslogd_t shell_exec_t:file { execute execute_no_trans \
getattr read };
# combine into this one rule
can_exec(syslog_t, { bin_t shell_exec_t } )
|
You also see in the rules that two of the rules are from
syslog-ng attempting to use a directory in
/usr/ of the type usr_t:
# These rules can be eliminated by properly labeling
# the files in the target location.
allow syslogd_t usr_t:dir { add_name remove_name write };
allow syslogd_t usr_t:file { append create getattr read setattr \
unlink write };
|
Your configuration uses a directory in /usr/ to write log files to. Because this log data
is not user data, it should have an appropriate label, var_log_t.
# If syslog-ng is configured to put logs in /usr/local/logs/,
# relabel that directory, and new files in the directory
# inherit the proper type.
chcon -R -t var_log_t /usr/local/logs/
|
Now you can trim the rules in $SELINUX_SRC/domains/misc/local.te to read:
can_exec(syslog_t, { bin_t shell_exec_t } )
allow syslogd_t etc_runtime_t:file { getattr read };
allow syslogd_t proc_kmsg_t:file write;
allow syslogd_t proc_t:file { getattr read };
allow syslogd_t bin_t:lnk_file read;
allow syslogd_t sbin_t:dir search;
allow syslogd_t self:capability { chown fowner fsetid sys_admin };
|
You also need to make an appropriate file contexts file so that
the labeling is maintained during relabeling operations. Put the
following context declaration in /etc/selinux/targeted/src/policy/file_contexts/misc/local.fc:
/usr/syslog(/.*)? system_u:object_r:var_log_t
|
