Thursday, February 05, 2009

SELinux - troubleshooting file labeling issues

This is a follow-up to SELinux - dealing with exceptions.

First off, a few basics:

chcon should only be used for temporary changes. See SELinux Contexts - Labeling Files. Changes made with chcon will not survive a file system relabeling or use of the restorecon command.

/usr/sbin/semanage fcontext will permanently change the file context in a manner that will survive a relabel or restorecon. See 5.7.2. Persistent Changes: semanage fcontext in the Fedora 10 documentation.

How do I find out what file labels were defined already for a package?

This is a bit trickier, but the key lies in looking under the following directory tree:

/etc/selinux/targeted/contexts/

For file labels, look at the file_context* files under:

/etc/selinux/targeted/contexts/files/

For example, I want to see what file contexts are defined for Nagios:

# grep -h "nagios" /etc/selinux/targeted/contexts/files/file_contexts*
/usr/lib(64)?/nagios/cgi(/.*)?  system_u:object_r:httpd_nagios_script_exec_t:s0
/usr/lib(64)?/nagios/plugins(/.*)?      system_u:object_r:bin_t:s0
/usr/lib(64)?/nagios/cgi-bin(/.*)?      system_u:object_r:httpd_nagios_script_exec_t:s0
/usr/lib(64)?/cgi-bin/nagios(/.+)?      system_u:object_r:httpd_nagios_script_exec_t:s0
/usr/lib(64)?/cgi-bin/netsaint(/.*)?    system_u:object_r:httpd_nagios_script_exec_t:s0
/etc/nagios(/.*)?       system_u:object_r:nagios_etc_t:s0
/var/log/nagios(/.*)?   system_u:object_r:nagios_log_t:s0
/var/log/netsaint(/.*)? system_u:object_r:nagios_log_t:s0
/var/spool/nagios(/.*)? system_u:object_r:nagios_spool_t:s0
/usr/bin/nagios --      system_u:object_r:nagios_exec_t:s0
/etc/nagios/nrpe\.cfg   --      system_u:object_r:nrpe_etc_t:s0


You can also use the seinfo tool:

# seinfo -t | grep "nagios"
Rule loading disabled
nagios_spool_t
httpd_nagios_script_ra_t
httpd_nagios_script_ro_t
httpd_nagios_script_rw_t
nagios_t
httpd_nagios_script_t
nagios_tmp_t
httpd_nagios_htaccess_t
nagios_var_run_t
httpd_nagios_content_t
nagios_exec_t
httpd_nagios_script_exec_t
nagios_etc_t
nagios_log_t


Another tool is sesearch, i.e.:

# sesearch -a | grep "nagios" | sort | uniq

Troubleshooting and fixing things

Thus, step #1 is generally that we need to figure out whether (A) the AVC denial was caused by a mislabeled file. And if so, we need to change the file label.

Here's an example of what setroubleshoot log messages look like in the /var/log/messages file.

# grep "setroubleshoot" /var/log/messages
setroubleshoot: SELinux is preventing the status.cgi from using potentially mislabeled files ./objects.cache (var_t). For complete SELinux messages. run sealert -l ce49f540-0b35-412c-862c-b901a274a421

setroubleshoot: SELinux is preventing ping (ping_t) "read write" to /var/nagios/spool/checkresults/checkZKmcmr (var_t). For complete SELinux messages. run sealert -l cf227199-1595-4775-9970-3935fc761b38

setroubleshoot: SELinux is preventing ping (ping_t) "read write" to /var/nagios/spool/checkresults/checke4tQgY (var_t). For complete SELinux messages. run sealert -l dbdc707e-193a-4f64-9bf2-0bb0d0a807e9


And here's what they look like in /var/log/audit:

# grep "AVC" /var/log/audit/audit.log | tail

type=AVC msg=audit(1233836684.122:15494): avc: denied { read } for pid=12081 comm="status.cgi" name="objects.cache" dev=md1 ino=1306897 scontext=system_u:system_r:httpd_nagios_script_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file

type=AVC msg=audit(1233836426.120:15476): avc: denied { read write } for pid=7518 comm="ping" path="/var/nagios/spool/checkresults/checkZKmcmr" dev=md1 ino=1306899 scontext=user_u:system_r:ping_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file

type=AVC msg=audit(1233836366.097:15454): avc: denied { read write } for pid=20671 comm="ping" path="/var/nagios/spool/checkresults/checke4tQgY" dev=md1 ino=1306899 scontext=user_u:system_r:ping_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file


In this particular case, the fact that the target context is "var_t" generally indicates a labeling issue. The "var_t" file context is pretty generic and we don't want to give the source context (httpd_nagios_script_t) for status.cgi permissions to all files labeled with var_t (which would be most of /var).

This means that using audit2allow is the wrong fix for this particular issue.

The correct solution is to either find out what file context should be used, or create a context and grant nagios access to those files.

References:

Fedora 10 Security-Enhanced Linux User Guide

Top three things to understand in fixing SELinux problems. Reposted

Fedora SELinux Project Pages (wiki)

Red Hat Enterprise Linux 4: Red Hat SELinux Guide

How to: Install and Setup XEN Virtualization Software on CentOS Linux 5 - Covers how to use semanage to grant the Xen process access to a directory where it will store the DomU storage as files.

Updates:

Earlier, I mentioned that audit2allow was really not the best way to approach file context issues. Now that I've learned a bit more, I can point you in a better direction.

1) semanage fcontext -a -t (newcontext) /full/path/to/filename

The "semanage" tool creates (or updates) a file under /etc/selinux/targeted/contexts/files. (Replace the word "targeted" with the current SELinux policy that you are using.) The file it creates is called "file_contexts.local".

"semanage" is used to create file contexts that will survive a system relabeling. So to properly change the file context on a path, you will use the "semanage fcontext" command then use "restorecon -vv -F" to fix the file / directory.

Note that you must supply a full path with a leading slash, otherwise you may find that restorecon does the wrong thing in other directories to files that also happen to match the pattern.

2) Using semanage to see what the default context is for a particular file

# semanage fcontext -l | grep '/some/path'

Note that this will not tell you where / what policy (whether part of the base SELinux package or whether it's a custom/local policy change). If you want to figure out whether it is a local change, then you should grep the files under /etc/selinux/targeted/contexts/files.

3) Relabing using restorecon.

"restorecon -v" will tell you which files get relabeled.

"restorecon -vv" will additionally tell you about files that did not get relabeled.

"restorecon -F" can be used to force a file back to the correct context as defined in the SELinux policy files.

3 comments:

Anonymous said...

hi,

your blog is cool. I found some of your posts helpful. Sounds like you really know what the heck is going on in the sauces :)

keep up the good work

Anonymous said...

This seems like a cop-out. You say don't use audit2allow, but then you don't really give enough information to solve this particular problem.

Thomas said...

It's a bit of a cop-out because I got interrupted while writing this and never got to revisit it.

Hopefully, now that I've been prodded, I'll remember to come back and update this.