Chapter 5. Troubleshooting problems related to SELinux

Procedure

1. Because the SELinux decisions, such as allowing or disallowing access, are cached and this cache is known as 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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   # semodule -B

   Copy to Clipboard Toggle word wrap

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

     Copy to Clipboard Toggle word wrap
   • Repeat your scenario.

   If the problem persists, something other than SELinux is blocking your scenario.

Procedure

1. List more details about a logged denial using the sealert command, for example:

   $ sealert -l "*"
   SELinux is preventing /usr/bin/passwd from write access on the file
   /root/test.
   
   *****  Plugin leaks (86.2 confidence) suggests *****************************
   
   If you want to ignore passwd trying to write access the test file,
   because you believe it should not need this access.
   Then you should report this as a bug.
   You can generate a local policy module to dontaudit this access.
   Do
   # ausearch -x /usr/bin/passwd --raw | audit2allow -D -M my-passwd
   # semodule -X 300 -i my-passwd.pp
   
   *****  Plugin catchall (14.7 confidence) suggests **************************
   …
   Raw Audit Messages
   type=AVC msg=audit(1553609555.619:127): avc:  denied  { write } for
   pid=4097 comm="passwd" path="/root/test" dev="dm-0" ino=17142697
   scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023
   tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0
   …
   Hash: passwd,passwd_t,admin_home_t,file,write

   Copy to Clipboard Toggle word wrap

2. If the output obtained in the previous step does not contain clear suggestions:

   • Enable full-path auditing to see full paths to accessed objects and to make additional Linux Audit event fields visible:

     # auditctl -w /etc/shadow -p w -k shadow-write

     Copy to Clipboard Toggle word wrap

   • Clear the setroubleshoot cache:

     # rm -f /var/lib/setroubleshoot/setroubleshoot.xml

     Copy to Clipboard Toggle word wrap
   • Reproduce the problem.

   • Repeat step 1.

     After you finish the process, disable full-path auditing:

     # auditctl -W /etc/shadow -p w -k shadow-write

     Copy to Clipboard Toggle word wrap
3. If sealert returns only catchall suggestions or suggests adding a new rule by using the audit2allow command, match your problem with examples listed and explained in SELinux denials in the Audit log.

Procedure

1. Open a new .cil file with a text editor, for example:

   # vi <local_module>.cil

   Copy to Clipboard Toggle word wrap

   To keep your local modules better organized, use the local_ prefix in the names of local SELinux policy modules.

2. Insert the custom rules from a Known Issue or a Red Hat Solution.

   Important

   Do not write your own rules. Use only the rules provided in a specific Known Issue or Red Hat Solution.

   • For example, to resolve SELinux denies cups-lpd read access to cups.sock in RHEL, insert the following rule:

     (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read)))

     Copy to Clipboard Toggle word wrap

     The example solution is fixed permanently for {ProductShortName} in RHBA-2021:4420. Therefore, the parts of this procedure specific to this solution do not affect updated {ProductShortName} 8 and 9 systems, and are included only as examples of syntax.

     You can use either of the two SELinux rule syntaxes, Common Intermediate Language (CIL) and m4. For example, (allow cupsd_lpd_t cupsd_var_run_t (sock_file (read))) in CIL is equivalent to the following in m4:

     module local_cupslpd-read-cupssock 1.0;
     
     require {
         type cupsd_var_run_t;
         type cupsd_lpd_t;
         class sock_file read;
     }
     
     #============= cupsd_lpd_t ==============
     allow cupsd_lpd_t cupsd_var_run_t:sock_file read;

     Copy to Clipboard Toggle word wrap
3. Save and close the file.

4. Install the policy module:

   # semodule -i <local_module>.cil

   Copy to Clipboard Toggle word wrap

   If you want to remove a local policy module you created by using semodule -i, refer to the module name without the .cil suffix. To remove a local policy module, use semodule -r <local_module>.

5. Restart any services related to the rules:

   # systemctl restart <service_name>

   Copy to Clipboard Toggle word wrap

Verification

1. List the local modules installed in your SELinux policy:

   # semodule -lfull | grep "local_"
   400 local_module  cil

   Copy to Clipboard Toggle word wrap

   Because local modules have priority 400, you can filter them from the list also by using that value, for example, by using the semodule -lfull | grep -v ^100 command.

2. Search the SELinux policy for the relevant allow rules:

   # sesearch -A --source=<SOURCENAME> --target=<TARGETNAME> --class=<CLASSNAME> --perm=<P1>,<P2>

   Copy to Clipboard Toggle word wrap

   Where <SOURCENAME> is the source SELinux type, <TARGETNAME> is the target SELinux type, <CLASSNAME> is the security class or object class name, and <P1> and <P2> are the specific permissions of the rule.

   For example, to resolve SELinux denies cups-lpd read access to cups.sock in RHEL:

   # sesearch -A --source=cupsd_lpd_t --target=cupsd_var_run_t --class=sock_file --perm=read
   allow cupsd_lpd_t cupsd_var_run_t:sock_file { append getattr open read write };

   Copy to Clipboard Toggle word wrap

   The last line should now include the read operation.

3. Verify that the relevant service runs confined by SELinux:

   1. Identify the process related to the relevant service:

      $ systemctl status <service_name>

      Copy to Clipboard Toggle word wrap

   2. Check the SELinux context of the process listed in the output of the previous command:

      $ ps -efZ | grep <process_name>

      Copy to Clipboard Toggle word wrap

4. Verify that the service does not cause any SELinux denials:

   # ausearch -m AVC -i -ts recent
   <no matches>

   Copy to Clipboard Toggle word wrap

   The -i option interprets the numeric values into human-readable text.