Troubleshooting SELinux Issues on CentOS and Red Hat

Overview

Many server administrators disable SELinux soon after deploying CentOS or Red Hat. The reason why is typically because their application will not run with it enabled or that a vendor recommended turning it off.

Disabling SELinux instead of troubleshooting and understanding why something is being blocked removes a key part of your system security. But how do you troubleshoot and discover the root cause of SELinux blocking your application? With a tool called setroubleshoot.

Setroubleshoot explains in plain English why a script or an application was blocked from executing. The tool also gives you suggestions on how to resolve the issue, which may involve running a simple command.

Auditing the SELinux Audit Log

You can investigate SELinux issues without any tools by opening the audit log it generates. This log is found at /var/log/audit/audit.log. However, unless you know exactly what to look for and have a lot of free time, you’re going to find it difficult making sense of the log.

So what do you do? Well, this is where two very crucial packages called Setools and Setroubleshoot come in handy. They will translate the gobbledegook we see in the log into something more meaningful.

Installing Setools and Setroubleshoot

1. Log into your server or desktop using an account granted administrative rights.
2. Open a command shell.
3. Install setroubleshoot packages using Yum.

   yum install setroubleshoot setools

SELinux Alerts

We now have a tool called sealert that analyzes the audit log used by SELinux. Sealert will scan the log file and report and will then generate a report containing all discovered SELinux issues.

To run sealert from the command-line, we need to point it to the SELinux audit log.

sealert -a /var/log/audit/audit.log

Each report will describe each issue and explain how to resolve them. An example of the output generated by sealert is seen below. I’ve truncated it to make the report easier to read.

100% donefound 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing /usr/sbin/httpd from getattr access on the file /myapps/app1/html/index.html.

*****  Plugin catchall_labels (83.8 confidence) suggests  ********************

If you want to allow httpd to have getattr access on the index.html file
Then you need to change the label on /myapps/app1/html/index.html
Do
# semanage fcontext -a -t FILE_TYPE '/myapps/app1/html/index.html'
where FILE_TYPE is one of the following: sssd_var_lib_t, public_content_t, anon_inodefs_t,

[..truncated..]

httpd_sys_ra_content_t, httpd_sys_rw_content_t, httpd_sys_rw_content_t, httpd_w3c_validator_content_t.
Then execute:
restorecon -v '/myapps/app1/html/index.html'

*****  Plugin catchall (17.1 confidence) suggests  ***************************

If you believe that httpd should be allowed getattr access on the index.html file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

The most important part of the report is found at the end of each alert. This is where it explains how to resolve the problem. For example, the report above shows the following solution.

If you believe that httpd should be allowed getattr access on the index.html file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

The solution given creates an SELinux policy that will then be applied to the problematic file, which, in my example, was an HTML file assigned the wrong SELinux file context.

SELinux Alerts on the Desktop

If you are running the Gnome desktop with the two packages installed, setroubleshoot and setools, you will receive alerts anytime SELinux blocks something. An example of an alert being generated can be seen below.

To get a detailed description of why the alert was generated, you can click the Show link in the alert box. When you click the Show link, the following dialog box will appear.

Right away we can determine the cause to be the Apache web server (usr/sbin/httpd) attempting to access a file called index.html. You can get a very detailed synopsis of why SELinux blocked Apache from accessing index.html. Although better than the output of the audit log, it’s still a pretty beefy read. Hpwever, it may be useful for really tricky situations in complex environments.

To simply get a quick solution to resolve the problem – allowing Apache access to the index.html file, we can click the Troubleshoot button.

We want Apache (httpd) to have getattr access on the index.html file, to allow it to be served to a user when they access our website. The solution presented to us explains that we need to do the following:

1. Apply the appropriate SELinux file context for Apache (httpd_sys_content_t) to the index.html file by running the following command to create a policy for it:

   semanage fcontext -a -t httpd_sys_content_t '/webapps/app1/html/index.html'

2. With the policy created, we now can apply it to the file anytime by using the restorecon command.

   restorecon -v '/mywebapps/app1/html/index.html'

SELinux Alert History on the Desktop

A history of alerts generated by SELinux can be view by using the SELinux Audit Log Analysis application. This allows you to easily audit SELinux-related problems that occurred while you were logged out of the server.

1. To see a history of alerts click the Application menu, expand System Tools, and then click SELinux Audit Log Analysis.

   

2. When the application launches, you will be presented with a list of all alerts found in the SELinux audit log.