SELinux in production — the workflow that actually works, and the AVC denials we keep finding

"Setenforce 0" is not a security strategy. It is, however, the most common "fix" we see for SELinux denials on customer hosts. The reasoning is always the same: an application broke, the error message mentioned SELinux, someone disabled SELinux, the application started working, and nobody went back.

This is the SELinux workflow we use on every managed RHEL host. The premise: SELinux stays in enforcing mode. Custom policy is small and version-controlled. Debugging follows a known set of steps, in order.

Debugging an AVC denial

# Step 1 — what was denied?
ausearch -m AVC -ts recent | grep denied
 
# Step 2 — get the human-readable explanation
sealert -a /var/log/audit/audit.log
 
# Step 3 — generate a candidate policy module (review before applying)
ausearch -m AVC -ts recent | audit2allow -M my_app_policy
# READ THE my_app_policy.te FILE. Do not just apply it.
 
# Step 4 — if the policy is reasonable, install it
semodule -i my_app_policy.pp

Step 3 is the one most teams skip. audit2allow is happy to generate a policy that's far too broad. Review the .te file. Trim what shouldn't be there. Then apply.

The full write-up covers:

• The five-step debug workflow in order (and what to do if step 4 isn't enough)
• The targeted policy — what it covers and where to extend
• semanage fcontext patterns for non-standard file paths
• SELinux booleans (getsebool -a | grep <service>) for the easy fixes
• File contexts that survive a restorecon
• The monitored boolean list we alert on (turning one off is a red flag)

We run this workflow on every managed RHEL host. SELinux stays on.