SELinux: Why it's time to stop turning it off

We hear it over and over again, how Linux is more secure—yada..yada..yada…. While that can be true its only true if the computer environment is configured properly. Security is done in layers, and often layers that seem troublesome are removed, which can result in increased risk for the organization. SELinux is one of those layers that can seem more trouble than it's worth. That may have been the case in the past, but new tools and better documentation mean this layer can be applied with relative ease.

Using and troubleshooting SELinux 

SELinux is a set of policies that state whether something is allowed to happen.  If there is no policy to allow it, then that action is denied. No ifs, ands, or buts.  Even if the user is root and permissions are 777 (read my colleague's blog) if there is no policy, you are denied.

The problems arise when those denials are preventing the desired result. In the past it was difficult to determine what SELinux was preventing or why. So, graybeards like, myself included, would simply place SELinux in permissive mode or turn it off completely.

With journalctl and setroubleshoot now the cause and the resolution are just a few commands, or dare I say it: ‘mouse clicks away’.

Here we have the fault indicated in red text in the terminal. Then we have the fix displayed in the comments.  If you want to resolve this execute:

            ausearch -c ‘systemd-logind’ –raw| audit2allow -M my-systemdlogind

            semodule -X 300 -i my-systemdlogind

This will create the SELinux policy to allow that action.

But if you don’t want to deal with CLI, there are alternatives. With X-windows or Cockpit, you can use UI tools that make displaying the error and implementing the resolution quicker and easier than working out of CLI.

Now, armed with this knowledge, go forth and add those extra layers of security, and as always, our iuvonauts can assist implementing SELinux in new and existing environments.

Contact us to learn more.