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
Once you have identified that there is an SELinux issue, you can investigate it using the indications in this section. If you can't figure it out, or if the issue is not specific to your system, please open a bug.
Ruling out issues due to inconsistent labeling
Moving Files
SELinux types are applied to a file when it is created. You can see these types with `ls -lZ`. When a file is moved, its 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* automatically change its type to httpd_file_t.
This is a feature, to prevent accidentally disclosing information that shouldn't be disclosed.
To avoid this, you can use "mv -Z src dst" to have the file's type label updated to the default for the destination during the move. Alternatively, after you do the move you can use `restorecon -v dst` to reset the types to the default for the destination.
Relabeling your system
If you see a lot of SELinux denials on your system, type labels could have ended up in an inconsistent state. To try to fix it, you can relabel your system. This can be done manually with:
touch /.autorelabel reboot
Or you can trigger relabeling (this will reboot your system) with:
systemctl start selinux-autorelabel
Use audit2why to dig deeper
There are various 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 inconsistency, 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. For example, the tool could recommend 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
If you understand the suggestion and the possible risks, you can enable the boolean.
Set a SELinux boolean
SELinux booleans are the intended way to tweak SELinux behaviour on your system as an administrator (see 'man 8 booleans'). To get the description of a boolean you can run semanage (from policycoreutils-python-utils package), and to see the changes a boolean does you can 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 example issue above should be resolved.
audit2allow
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;