Portal:SELinux/Troubleshooting

Is it a SELinux problem?

If something does not work as intended, for example because of a denied permission, SELinux could be the culprit. There are some ways to figure out if the issue has to do with SELinux.

Check audit log

First, you can check the audit log for AVC denial entries. If you see AVC denials in the log, this is a strong hint that the problem is caused by SELinux:

List SELinux related audit events since boot

   # ausearch -ts boot -m avc

Instead of "boot" other useful options are "today" or "recent".

Example of AVC denials in audit log

   # ausearch -ts recent -m avc -c sshd
   ----
   time->Tue May 18 14:47:47 2021
   type=AVC msg=audit(1621342067.432:82): avc:  denied  { read } for  pid=839 comm="sshd" name="example.com.3" dev="vda2" ino=199155 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_yp_t:s0 tclass=file permissive=1
   ----
   time->Tue May 18 14:47:47 2021
   type=AVC msg=audit(1621342067.432:83): avc:  denied  { open } for  pid=839 comm="sshd" path="/var/yp/binding/example.com.3" dev="vda2" ino=199155 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_yp_t:s0 tclass=file permissive=1
   [...]

If you see AVC denials in your audit log, please go to the Portal:SELinux/Troubleshooting#Investigating_Denials section for guidance on investigating the issue.

There are no AVC denials, could it still be SELinux?

If nothing shows up but you want to rule out SELinux as problem entirely, try to temporarily set SELinux to permissive and check if the problem persists:

   setenforce 0

If the issue goes away when SELinux is set to permissive, then SELinux is the culprit.

To set SELinux to enforcing again, run:

   setenforce 1

Please open a bug in the case where there are no AVC denials and disabling SELinux fixes the problem. To make it easier for us, please set SELinux to enforcing again and rebuild the policy without the so-called "dontaudit" rules:

   semodule -DB

Then, rerun your failing program. This should give you some AVC in the audit log, please include them in your bugreport. Then, you can rebuild the policy back to normal again with:

   semodule -B

Investigating Denials

If you can't fix it yourself please open a bug

Ruling out issues due to inconsistent labeling

Moving Files

SELinux types are applied to a file when it is created. When a file is moved, it's type remains the same. A common example of this is if you copy a file to a server with scp to your home directory it will be labeled `user_home_t`. If you wanted to then move that file to `/var/www/html` to be served by a webserver, the file would *not* change it's type to `httpd_file_t`.

This is a feature, to prevent accidentally disclosing information that shouldn't be disclosed!

You can see these types with `ls -lZ`.

To avoid this you can use "mv -Z src dst" to have the files type updated during the move. Alternately after you do the move you can use `restorecon -v dst` to reset the types.

Relabeling your system

Sometimes if things are inconsistent this can lead to a lot of denials in selinux. You should relabel your filesystem in these cases.

You can trigger this with `systemctl start selinux-autorelabel`. This WILL reboot your system.

Use audit2why to dig deeper

There are different reasons why SELinux could have denied an access that are not due to inconsistencies in the system. After making sure the issue is not caused due an inconsitency, the easiest way to get a hint of the reason is to use the audit2why tool:

The output of the audit log in the format provided by ausearch can be piped through audit2why (from policycoreutils-python-utils package) which potentially gives some explanation. In this case the tool recommends turning on a boolean:

   ausearch -ts recent -m avc | audit2why

   Was caused by:
   The boolean nis_enabled was set incorrectly. 
   Description:
   Allow nis to enabled
   
   Allow access by executing:
   # setsebool -P nis_enabled 1

Following the instruction to use setsebool would resolve the issue in this case. SELinux booleans are the intended way to tweak your system as a system administrator, great!

Set a SELinux boolean

To get the description of a boolean run semanage (from policycoreutils-python-utils package) and to see the changes a boolean does run sesearch (from setools-console):

semanage boolean -l | grep nis_enabled

sesearch -A -b nis_enabled

To set the boolean, you can use:

setsebool -P nis_enabled 1

After setting the boolean, the issue should be resolved.

audit2allow

Danger zone! We do not recommend this for beginners! This can and will add rules that are too broad and could undermine the security that SELinux provides or cause more SELinux problems. Only do this if you know what you are doing! If in doubt, open a bug!

Another suggestion given by audit2why could look like this:

  Was caused by:
               Missing type enforcement (TE) allow rule.
               You can use audit2allow to generate a loadable module to allow this access.

That one recommends to use audit2allow (from policycoreutils-python-utils package) to produce a new rule.

The audit2allow tool uses audit messages to produce rules that can be loaded into SELinux after conversion into the correct format.

For example, having this AVC in the file `my_avc`:

   type=AVC msg=audit(1621342040.556:15): avc:  denied  { watch } for  pid=1 comm="systemd" path="/var/cache/cups" dev="vda2" ino=22stem_r:init_t:s0 tcontext=system_u:object_r:cupsd_rw_etc_t:s0 tclass=dir permissive=1

audit2allow would suggest this rule:

   cat my_avc | audit2allow

   #============= init_t ==============
   allow init_t cupsd_rw_etc_t:dir watch;