Problem solve Get help with specific problems with your technologies, process and projects.

Manage SELinux policies for better troubleshooting, access controls

The three different SELinux modes -- Enforcing, Permissive and Disabled -- dictate how admins can secure and troubleshoot applications with the SELinux system.

Security-Enhanced Linux is an advanced access control mechanism built into most modern Linux distributions. With Security-Enhanced Linux in place, administrators use policies to better manage security.

But these policies are key to not only the security of a system, but to its functionality. For example, Security-Enhanced Linux (SELinux) allows applications to query a policy; admins to control process initialization, inheritance and program execution; and admins to manage files, file systems, directories, sockets, open file descriptors, messaging interfaces and network interfaces. It also allows for in-place policy changes -- the ability to alter SELinux policies without rebooting the system.

SELinux works by implementing mandatory access control (MAC) on top of discretionary access control (DAC) to protect systems from intrusion. DAC restricts access to objects -- or resources such as files, sockets, pipes or network interfaces -- based on the specific identity of subjects, or processes, and/or groups to which the subjects belong. MAC constrains the ability of a subject to access objects or perform some sort of operation on an object or target.

SELinux modes

SELinux can be set to three different modes:

Enforcing: SELinux denies access based on the rules laid out by SELinux policies;

Permissive: SELinux does not deny access, but logs all denials; and

Disabled: SELinux is disabled.

It is not recommended to set SELinux to Disabled mode. Sometimes, admins use this mode because the SELinux system is complicated and, when poorly managed, can easily get in the way of application functionality. For instance, an admin might roll out a software as a service (SaaS) application and then discover it isn't functioning properly. After a quick dive into log files, the admin finds SELinux to be the culprit and shuts it down -- but this disables a powerful security tool.

Troubleshooting with SELinux

If your newly deployed SaaS app -- or whichever system or service you've developed -- fails because of SELinux policies, it's best to troubleshoot in Permissive mode.

SELinux does a solid job logging events. This is where an administrator should always start when a problem arises. By default, SELinux logs everything to /var/log/audit/audit.log. When an app's functionality goes awry -- assuming you're certain the issue doesn't lie in the application code -- the SELinux log file is the first stop for troubleshooting. Standard users must su to root to view the SELinux log (Figure A).

Log file
The SELinux log file on a CentOS 7 server.

It can be cumbersome to comb through the audit log, but it can help understand exactly what is going on. Look specifically for entries marked denied. Those entries will list information such as the Process ID, User ID, the permission requested, the process command and the target name. With this information, you can discover why SELinux and your app/service do not work together.

The GUI alternative

If you happen to be running a server with a GUI, the SELinux Alert Browser is a must-use tool. When SELinux detects a problem, an alert will appear. Click on the alert, type your root user password and the SELinux Alert Browser will appear.

Out of the box, SELinux should be set to Enforcing mode. If SELinux sees a problem with your app or service, it will deny it from running. You can alter the default policy from Enforcing to Permissive so that SELinux will allow the service to run, while logging all denials for the purpose of troubleshooting. When you run into such a problem, you can change from Enforcing to Permissive with the following steps:

1.            Open a terminal window

2.            Issue the command sudo nano /etc/sysconfig/selinux

3.            Change SELINUX=enforcing to SELINUX=permissive

4.            Save and close the file

5.            Reboot the server

To ensure the status has changed, issue the command sestatus. This command will tell you everything you need to know about the current state of SELinux (Figure B).

Permissive mode
SELinux is enabled and in Permissive mode.

At this point, your application will work and SELinux will log all denials so you can locate the problem.

Modifying SELinux policies

Say, for example, you have a SaaS application, served up via the Apache server, and it's not functioning properly.

This is under the assumption that Apache is serving up websites/services from an alternative document root, which is likely the reason that SELinux is having problems. The alternative document root for our example is /srv/www/. You set everything up properly for Apache, but the websites aren't served up from the alternative document root. You went through the /var/log/audit/audit.log and discovered SELinux as the culprit. The problem is that SELinux doesn't know about the alternative document root.

First, find out some specifics on what a legit file -- we'll use /var/www/html/index.html -- from the standard document root would have so we can adjust accordingly for the alternative document root. To find out this information, issue the following command:

ls -lZ /var/www/html/index.html

The output for this command will look like that seen in Figure C.

Command output
The output for the command 'ls -lZ /var/www/html/index.html'

Use the command semanage fcontext -l | grep '/var/www' to list out all fcontext entries, or file contexts within the /var/www/ folder, which will return the same context type, which is httpd_sys_content_t in this example. Then, instruct SELinux to enable this type of file to be served up within the /srv/www/ directory. To do this, alter the policy with the help of the semanage command:

semanage fcontext -a -t httpd_sys_content_t '/srv/www(/.*)?'

The above command instructs semanage to add the new fcontext with the type httpd_sys_content_t, and apply it to the directory /srv/www, as well as any subdirectories and files. At this point, issue the command semanage fcontext -l | grep '/srv/www' to see your files in /srv/www and verify the httpd_sys_content_t context is in place. Now issue the command restorecon -Rv /srv/www, which will relabel and set the appropriate security context for the /srv/www directory, as well as any subdirectories and files according to newly edited SELinux policies.

Now, Apache can serve up content from the /srv/www directory without hiccups from SELinux. With your problem resolved, switch SELinux from Permissive to Enforcing using the same steps for switching from Enforcing to Permissive.

Next Steps

RHEL 7.3 offers new SELinux features

SELinux on SUSE adds business security

Compare the leading enterprise Linux distros

Dig Deeper on Linux servers