Identifying whether SELinux is to blame

Before blaming the SELinux subsystem and policies for a problem, it is important to verify whether SELinux is to blame at all. Too often, hours of troubleshooting are put in analyzing the SELinux policies and subsystem only to find out that the problem also persists when SELinux is not enabled.

How to do it…

In order to be confident that SELinux is (or isn't) to blame, the following set of steps can be taken:

1. Is it possible to get more information through the application's internal debugging system? Consider the following instance:

   ~# puppet master
   Error: Could not find class puppet::agent for foo.bar on node foo.bar
   ~# puppet master --debug --no-daemonize --verbose

2. Is an AVC denial related to the problem shown in the audit logs? If not, try disabling the dontaudit rules and try again:

   ~# semodule -DB
   

3. Is the application that gives problems SELinux-aware? Most SELinux-aware applications are linked with the libselinux.so library, so we can verify whether...