SELinux commands you should know before giving up hope

Rather than giving up on SELinux and allowing permissions you shouldn't, use these SELinux commands to troubleshoot problems.

SELinux frequently causes problems for Linux system administrators. Too often, admins simply give up and shut off...

SELinux on servers. Usually, there's no reason for a complete shutdown; SELinux audit messages are not that hard to understand.

There are two ways to troubleshoot Security-Enhanced Linux: You can do it based on the interpreted messages in /var/log/messages, and based on the audit messages in /var/log/audit/audit.log. The purpose of the interpreted messages is to help the administrator understand the sometimes difficult messages in /var/log/audit/audit.log.

But the interpreted messages in /var/log/messages are so easy to understand, many system administrators never look beyond them, and they risk missing important information in the audit log.

The disadvantage of /var/log/messages is that these are interpretations of the audit log. Sometimes there is no easy interpretation available, which makes working with the sealert messages in /var/log/messages difficult. Often, there is no need to because the messages in /var/log/audit/audit.log are not that difficult to understand.

For example, consider the lines from /var/log/audit/audit.log. If you're looking for SELinux messages in this log file, examine the lines that contain the AVC message type:

Type=AVC msg=audit(1367976112.939:17): avc: denied { getattr } for pid=2642 comm="httpd" path="/web/index.html" dev=dm-0 ino=533696 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

The first thing indicated in this line is that a { getattr } system call has been denied for pid 2642, which is used by the httpd process, meaning your Web server has tried to get attributes on something.

Second, there's an indication on what it tried to access: the file /web/index.html. That is on the device dm-0 with inode number 533969, so the Web server has tried to read an index.html file to which it did not have the appropriate permissions.

Next, the audit log line shows the context that caused this denial. The source context of the offending process was set to unconfined_u, system_r and httpd_t. The target context on the file that it tried to access was set to unconfined_u, object_r and default_t.

When analyzing contexts in SELinux denial messages, usually only the last part is of interest. The denial line can be interpreted as follows: A process with the source context type httpd_t has tried to access a file with the context type default_t. And that is forbidden.

If you understand how SELinux works, it is easy to understand why that access is forbidden. SELinux is designed to allow processes access only to necessary files. That means a process that flagged as httpd_t can access only files that are labeled httpd_sys_content_t. When you don't know which context type to use on a target file or directory, check the main page for the service you need to configure, or use ls -Z on a default configuration file that may be flagged correctly.

After you discover what was wrong, enable access to the file. There are two methods: Set the expected context label on the target file, using semanage and restorecon, or use audit2allow to create a SELinux module. In either case, apply your solution only if you really know what's happening.

Usually, the easy fix is to set the context label using semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?". This command sets the right context label to the policy, after which you must enable it using the restorecon -R -v /web command.

Another way to fix the problem is with audit2allow. This command basically reads the audit.log file as the input file and creates a SELinux module that allows the action that was previously denied. This is a convenient but dangerous method for applying a fix. It is very easy to accidentally make the policy too permissive.

Before using audit2allow, isolate the log line you want to allow. Copy it to a temporary audit file, like audit_temp.log for best use. Next, use audit2allow -I audit_temp.log -M mymodule to create a SELinux module with the name mymodule. Once this module is loaded, it will allow the action that was previously denied. To allow the denied action, insert the module into the SELinux policy and use semodule -I mymodule.

Always use semanage first; it decreases the risks of accidentally allowing actions that shouldn't be allowed.

Sander van Vugt is an independent trainer and consultant based in the Netherlands. He is an expert in Linux high availability, virtualization and performance. He has authored many books on Linux topics, including Beginning the Linux Command Line, Beginning Ubuntu LTS Server Administration and Pro Ubuntu Server Administration. He can be reached at [email protected].

Dig Deeper on Linux servers