5장. Troubleshooting problems related to SELinux

Procedure

1. When your scenario is blocked by SELinux, the /var/log/audit/audit.log file is the first place to check for more information about a denial. To query Audit logs, use the ausearch tool. Because the SELinux decisions, such as allowing or disallowing access, are cached and this cache is known as the Access Vector Cache (AVC), use the AVC and USER_AVC values for the message type parameter, for example:

   # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

   If there are no matches, check if the Audit daemon is running. If it does not, repeat the denied scenario after you start auditd and check the Audit log again.

2. In case auditd is running, but there are no matches in the output of ausearch, check messages provided by the systemd Journal:

   # journalctl -t setroubleshoot

3. If SELinux is active and the Audit daemon is not running on your system, then search for certain SELinux messages in the output of the dmesg command:

   # dmesg | grep -i -e type=1300 -e type=1400

4. Even after the previous three checks, it is still possible that you have not found anything. In this case, AVC denials can be silenced because of dontaudit rules.

   To temporarily disable dontaudit rules, allowing all denials to be logged:

   # semodule -DB

   After re-running your denied scenario and finding denial messages using the previous steps, the following command enables dontaudit rules in the policy again:

   # semodule -B

5. If you apply all four previous steps, and the problem still remains unidentified, consider if SELinux really blocks your scenario:

   • Switch to permissive mode:

     # setenforce 0
     $ getenforce
     Permissive

   • Repeat your scenario.

   If the problem still occurs, something different than SELinux is blocking your scenario.