Mastering SELinux: From Permissive to Enforcing Without Breaking Production

Why SELinux Still Matters

After 20 years of SELinux being shipped in Red Hat distributions, I still find most admins set it to permissive on day one and never look back. That's a mistake I've made myself — and one I've watched cost organisations real incidents.

SELinux is a mandatory access control (MAC) system. Even if an attacker gets code execution, SELinux can prevent them from reading /etc/shadow, binding to a network port, or writing outside a confined process's allowed paths.

Moving from Permissive to Enforcing Safely

The trick is audit first, enforce second.

# Check current mode
getenforce

# Put into permissive (log but don't block)
setenforce 0

# Scan audit log for would-be denials
ausearch -m avc -ts recent | audit2allow -a

# Generate a local policy module for what you've seen
audit2allow -a -M myapp
semodule -i myapp.pp

After a week of permissive with real traffic, flip to enforcing:

setenforce 1
# Make it permanent
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

Common Pitfalls

• Wrong file context after mv: use restorecon -Rv /path after moving files
• Port labelling: semanage port -a -t http_port_t -p tcp 8443
• Boolean toggles: getsebool -a | grep httpd then setsebool -P httpd_can_network_connect 1

Defensive Takeaways

• Never permanently disable SELinux — use policy modules instead of permissive mode
• Audit every avc: denied denial in permissive before going enforcing
• Custom apps need custom file contexts; document them in your runbook
• audit2why is your friend when a denial doesn't make sense