RHEL6 – SELinux Troubleshooting II: Electric Boogaloo

Little_Miss_Trouble_by_Percyfan94So a good while back I posted an article on how to troubleshoot SELinux violations and after reviewing that article as part of a troubleshooting exercise, I realized that I left out a few details. Needless to say my original article was not as clear as it should be. Anyway I wanted to use up a few more bytes of the internet to clarify.

When the package setroubleshoot-server is installed, SELinux violations will be sent to /var/log/messages, which makes it fairly easy to troubleshoot SELinux issues.

So first lets install setroubleshoot and all its parts

# yum install setroubleshoot*

In my case on RHEL6, the following packages were installed


Note that the setroubleshoot-server is the one that you need to troubleshoot via the command line.

Now lets generate a violation. In this case I am just dropping a file with the wrong selinux context into /var/www/html and am trying to access it.

# touch /root/file3 && cp /root/index.html /var/www/html/file3

Check the context if you must to make sure that its not correct for httpd content. In this case you can see that it is not.

# ls -lZ /var/www/html/file3
-rwxrwxrwx. root root system_u:object_r:admin_home_t:s0 /var/www/html/file3

Now start Apache and try to access the file via elinks or a browser. You will get a Forbidden error, which I have omitted below.

# elinks -dump http://localhost/file3

Note that you may need to restart auditd if your message does not show up in the messages file.

Aug 11 17:08:39 vfatmin01 setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/www/html/file3. For complete SELinux messages. run sealert -l 5a413022-af89-4222-b055-0cc1edc4bbad

Note: You will also find a the same error in /var/log/audit/audit.log, albeit in a bit less friendly format.

type=AVC msg=audit(1344719319.890:7196): avc:  denied  { getattr } for  pid=6765 comm=”httpd” path=”/var/www/html/file3″ dev=dm-1 ino=656718 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

Anyway back to the error from the messages file. At the end of the error you are shown the UUID of the error and the sealert command to run to get more information on the error.

# sealert -l 5a413022-af89-4222-b055-0cc1edc4bbad

Output below:

SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/www/html/file3.

*****  Plugin restorecon (99.5 confidence) suggests  *************************

If you want to fix the label.
/var/www/html/file3 default label should be httpd_sys_content_t.
Then you can run restorecon.
# /sbin/restorecon -v /var/www/html/file3

Wow, sealert actually tells you why the file is being blocked and the commands that you should run to fix the problem. Nice!

RHEL6 – Using Semanage and Restorecon to Modify SELinux File Contexts

Potty TrainingOk, how to keep this simple? Lets see…


Ok, semanage, when used with the fcontext argument, is used to define SELinux file contexts for file. It basically adds the new definition to the file,  /etc/selinux/targeted/contexts/files/file_contexts.

For example lets say that I create a new file called /root/foobar.

Using the command below I can see the default context that is assigned to a file created in /root

# ls -lZ foobar
-rw-r–r–. root root unconfined_u:object_r:admin_home_t:s0 foobar

Now lets say that I want to change the context of this file to public_content_t.  The first step to accomplish this is to define its new context.

# semanage fcontext -a -t public_content_t /root/foobar


Now that the context type is defined we need to actually modify the current context of our file. So now you run restorecon against the file to actually make the change. Note: use -v for verbose.

# restorecon -v /root/foobar

restorecon reset /root/foobar context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:public_content_t:s0


There is also a command called chcon, that can also be used to change the defined context for a file. However I advise against using it as changes made using chcon will not survive a filesystem relabel. What is a filesystem relabel? Well according to wiki.centos.org, a relabel is defined below.

“Sometimes it is necessary to relabel the complete filesystem although this should only be necessary when enabling SELinux after it has been disabled or when changing the SELinux policy from the default targeted policy to strict.”


RHEL6 — Troubleshooting SELinux Violations

Sad_face1Dear Reader: Welcome to my third and not final installment on SELinux. The first two can be read here and here. They are exciting reads and are sure to have you on the edge of your seat.

Anyway, the best way to implement SELinux sucessfully is to know how to troubleshoot when things aren’t going your way. If you panic at the first sign of trouble, you are just going to end up turning off SELinux and not reap the rich rewards that it will bring you in life. Now that I have convinced you to run SELinux lets get started.

First install the package setroubleshoot, which will send SELinux messages to our messages file.

yum -y install setroubleshoot-server.x86_64

Now you can search the messages file for SELinux Violations. Use sealert -l UUID to find information on a specific incident, or sealert -a  /var/log/audit.log to search an entire log file for violations.

In this specfic example, I created a test file and dropped it in /var/www/html, however I did not set the context to httpd_sys_content_t, then i attempted to view the file in a browser. Obviously access was denied. The output of sealert shows me the error and then tells me how to fix it.


SELinux is preventing /usr/sbin/httpd “getattr” access to /var/www/html/file3.

Detailed Description:

SELinux denied access requested by httpd. /var/www/html/file3 may be a
mislabeled. /var/www/html/file3 default SELinux type is httpd_sys_content_t, but
its current type is admin_home_t. Changing this file back to the default type,
may fix your problem.


Allowing Access:

You can restore the default system context to this file by executing the
restorecon command. restorecon ‘/var/www/html/file3’, if this file is a
directory, you can recursively restore using restorecon -R

Fix Command:

/sbin/restorecon ‘/var/www/html/file3’

Boom goes the dynomite! Problem solved.