How to troubleshoot SELinux issues?

Question

I suspect I have a problem in SELinux configuration: my issue goes away after disabling selinux using setenforce 0. I am using the default policy without any modifications.

How can I pinpoint the exact issue in SELinux configuration?

Answer 1

SELinux problems are logged in audit log, which usually is in /var/log/audit/audit.log. If auditd is not installed on your system, SELinux error messages are printed in kernel ring buffer and can be read with dmesg.

SELinux AVC (Access Vector Cache) messages have following format ^[src]:

type=AVC msg=audit(1220706212.937:70): avc:  denied  { getattr } for  pid=1904 comm="httpd" path="/var/www/html/testfile" dev=sda5 ino=247576 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0  tclass=file

It is also possible that there are no error messages. SELinux policy may contain dontaudit rules, which suppress logging for specific access. Dontaudit rules can be disabled with semanage:

semanage dontaudit off

(You probably want to turn dontaudit rules back on after solving the issue to reduce log noise.)

With an AVC message describing what access was denied, it is possible to narrow possible cause. Useful fields in the AVC message for troubleshooting are the comm, path, source and target contexts: comm contains the command line name of the process, path (for files) what file the access was to, source and target contexts the security labels.

Analyzing the error message audit2why can provide human readable description of the error message. Typical issues with default policy are caused incorrect security contexts, like in the message above, and could be investigated in two steps:

• Are source and target contexts correct?

  SELinux rules map allowed access between source and target security contexts. If there is no such rule, access is denied. In certain situations, the contexts can be incorrect, resulting in denied access.

  Incorrect target context

  Files might have incorrect security contexts, for example if they were moved (which preserves the original security contexts). Use restorecon to apply the default security label to the files.

  If you are not using the default locations for your files, you should to add the file labeling rule to file context database using semanage and run restorecon afterwards. For more details, see question: How to configure SELinux to allow daemons to use files in non-default locations?

  If the target type is not a file or directory (such as network port), the target context is likely managed using semanage.

  Incorrect source context

  Most system daemons run in confined domains (source context), such as httpd_, smbd_t, etc.

  If the daemon runs in init_t domain, there either isn't a targeted policy for it, the policy module is not enabled or there is an incorrectly labeled executable (entry point). If the process runs in unconfined_t domain, it suggests the process was launched by user and not by init system. In both cases there usually aren't any errors, because both domains place very few restrictions.

  A wrong source context (in a confined domain) for a process would indicate wrong file labeling at the executable, possibly due a missing SELinux policy module.

• Contexts are correct: the policy doesn't allow access

  The policy needs to be modified to allow the access. Common configurations might already be addressed by boolean options. audit2allow can tell if such boolean exists, or generate necessary policy module to allow the access.

Further reading

• Gentoo Wiki: SELinux/Tutorials/Where to find SELinux permission denial details
• Fedora 25 Documentation: SELinux User's and Administrator's Guide