SELinux custom policy troubleshooting notes

category: notez · date: 2018-01-01 · author: LALA

noteHistorical technical note from 2018. Environment-specific identifiers and credentials have been anonymized. Commands reflect the technology and operating-system generation used at the time and should be reviewed before reuse on a current system.

These were working notes for diagnosing SELinux denials affecting services such as Dovecot and systemd-machined. The useful lesson is the policy-development workflow; generated rules from the old environment are not reproduced because they were specific to its labels and services.

Recommended troubleshooting flow

Reproduce the denied operation, then inspect recent AVC records:

bash

$ ausearch -m AVC,USER_AVC -ts recent

Use audit2why to understand the denial:

bash

$ ausearch -m AVC -ts recent | audit2why

audit2allow can suggest policy, but its output is not automatically correct:

bash

$ ausearch -m AVC -ts recent | audit2allow -R

Review the suggested interfaces and permissions before adding them.

Check labeling first

A denial involving generic types such as default_t is often a sign of mislabeling. Inspect:

bash

$ ls -lZ /path/to/object
$ matchpathcon /path/to/object

Define persistent corrections with semanage fcontext, then apply with restorecon.

Avoid the automatic-fix anti-pattern

Do not blindly pipe an audit log into audit2allow -M and immediately install the generated module. It can grant permissions caused by bad labels, unrelated historical events or an application bug.

References

Red Hat - Writing a custom SELinux policy: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/writing-a-custom-selinux-policy_using-selinux
SELinux Project: https://selinuxproject.org/