Wednesday, January 10, 2018

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.

FIG1 – SELinux Audit 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

Log into your server or desktop using an account granted administrative rights.

Open a command shell.

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.

SELinux Alert on the Gnome Desktop

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.

SELinux Alert Browser Dialog Box

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.

SELinux Alert Browser Troubleshoot

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:

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:

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.

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

Applications Menu – Selinux Audit Log Analyzer

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