Fix Policy Problems

If you find (or suspect) that SELinux is preventing something from working correctly, then here are steps to diagnose and fix. NB These instructions only describe how to allow permissions between existing SELinux domains and types; creating new domains and/or types for new services/applications requires additional steps a priori; for that, see sepolicy-generate.8 or look at an existing example from the refpolicy.

1. Confirm that SELinux is actually enabled and enforcing

If not, then SELinux is not the problem so you do not need to proceed any further.

$ getenforce
Enforcing # Disabled or Permissive means SELinux is unlikely to be the culprit. Blame something else!

2. Confirm that the problem doesn't still happen if SELinux is permissive.

If it still happens, then SELinux isn't the problem so you don't need to proceed any further. If this is a production system and you don't want to put the entire system into permissive mode, try making just the failing process domain(s) permissive via semanage permissive.

sudo setenforce 0 # or semanage permissive -a <name-of-domain>
<try to reproduce problem>
sudo setenforce 1 # or semanage permissive -d <name-of-domain>

3. Check for SELinux-related audit messages that occurred while you reproduced the problem.

NB If you ran the selinux-testsuite earlier, make sure you exclude any audit messages from running it so that you don't add any rules on the test domains / types.

sudo ausearch -m avc,selinux_err,user_avc -ts today -i # if running auditd
sudo journalctl -k -S today | grep 'type=14[0-9][0-9]' # if not running auditd

4. If you don't get any SELinux-related audit messages that seem relevant to the problem, then turn on auditing of ALL denials by rebuilding the SELinux policy modules with dontaudit rules removed.

SELinux dontaudit rules silence noise from common library and application attempts to access something that they do not require for their operation. Removing the dontaudit rules will generate a lot of SELinux audit messages, most of which are irrelevant and can be ignored. You don't need to do this if you already saw relevant audit messages that would explain the problem in the previous step.

sudo semodule -DB
setenforce 0 # or semanage permissive -a <name-of-domain>
<retry the failing operation>
setenforce 1 # or semanage permissive -d <name-of-domain>

5. Generate a local policy module that allows all the permissions that were audited.

# <name-of-module> can be anything that isn't already used;
# run 'sudo semodule -l' for a list of currently installed modules.
# Good practice would be to use a common prefix for all local modules, 
# e.g. local_, followed by the name of the domain being modified, e.g. local_cockpit.
# As before, consider changing 'today' to a more precise time to only collect messages
# from when you were reproducing the problem.
# If running auditd:
sudo ausearch -m avc,user_avc -ts today -i | audit2allow -M <name-of-module>
# If not running auditd:
sudo journalctl -k -S today | grep avc | audit2allow -M <name-of-module>
# NB you may wish to add additional filters to the pipe and/or selectors to ausearch or journalctl
# before calling audit2allow to only select the avc denials relevant to the processes in question
# and avoid allowing unnecessary accesses to other processes.

6. Examine the generated module source files, especially the .te file, and if desired, edit to prune unnecessary/undesired permissions.

If there are no allow rules in the .te file or all of the allow rules are marked with a comment that says they are already allowed by the current policy, then missing allow rules are not the source of your problem; try audit2why instead (go to step 8). If you edit the .te file to remove some of the allow rules, rebuild the policy package file. This isn't necessary if you didn't make any changes to the .te file because audit2allow already compiled that to a .pp file.

vi <name-of-module>.te
make -f /usr/share/selinux/devel/Makefile <name-of-module>.pp

7. Install the policy module.

sudo semodule -i <name-of-module>.pp

8. Retry whatever was previously failing and see if it now works.

If not, there are at least two possible reasons: 1) you didn't get all the necessary audit messages earlier, in which case go to step 4 and try again; or 2) the denials are not due to missing allow rules in the TE policy, in which case pipe the ausearch or journalctl output into audit2why to find out other potential causes of the denials.

# As before, consider changing 'today' to a more precise time to only include denials from the problem.
# If running auditd:
sudo ausearch -m avc,user_avc -ts today -i | audit2why
# If not running auditd:
sudo journalctl -k -S today | grep avc | audit2why