🛡️ Fixing SELinux Denials Without Disabling It

The most common SELinux “fix” on the internet is setenforce 0, and it’s the worst possible advice. You’ve just disabled a working security layer to solve a problem that usually takes one command to fix properly. The reason people reach for it is simple: SELinux denials are intimidating to read.

After 25 years — and plenty of RHEL/Rocky boxes — here’s how I actually resolve denials, keep enforcing mode on, and use AI to translate the audit log into the correct fix.

First, confirm SELinux is actually the cause

Before assuming, check the mode and whether a denial happened:

getenforce              # Enforcing, Permissive, or Disabled
sudo ausearch -m avc -ts recent

If your app fails and ausearch shows a fresh AVC denial at the same time, SELinux is in the loop. If there’s no denial, your problem is something else — don’t blame SELinux for a permissions or config bug.

A quick diagnostic trick: temporarily set permissive (not disabled), reproduce, and see if it now works and logs denials:

sudo setenforce 0       # permissive, temporary, NOT a fix
# reproduce the problem
sudo setenforce 1       # back to enforcing immediately

If permissive mode makes it work, SELinux is the cause — now fix it properly and turn enforcing back on. Permissive is a diagnostic, never the destination.

Read the denial in plain English

Raw AVCs are dense, but sealert and audit2why decode them:

sudo ausearch -m avc -ts recent | audit2why

This tells you why it was denied and often suggests the fix. The three most common root causes:

1. Wrong file context — a file is labeled for the wrong purpose (e.g. web content not labeled httpd_sys_content_t).
2. A boolean is off — a policy toggle like “let httpd make network connections” is disabled.
3. A non-standard port — your service listens on a port SELinux doesn’t associate with it.

Fix 1: relabel files with the right context

The classic: you put web content in a non-standard directory and Apache can’t read it. Check the context:

ls -Z /srv/web/index.html

Compare with a working file under /var/www. Set the correct context persistently:

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
sudo restorecon -Rv /srv/web

semanage fcontext records the rule; restorecon applies it. Do it this way — not chcon — so the label survives a relabel.

Fix 2: flip the right boolean

Booleans are pre-built toggles for common needs. List them:

getsebool -a | grep httpd

Want Apache to make outbound connections (a reverse proxy, say)?

sudo setsebool -P httpd_can_network_connect on

The -P makes it persistent across reboots. Forgetting -P is why “it worked until I rebooted.”

Fix 3: register a non-standard port

Service on a custom port? Tell SELinux:

sudo semanage port -a -t http_port_t -p tcp 8443

Now the policy permits httpd to bind 8443.

Where AI is genuinely excellent

Translating a raw AVC into the exact semanage/setsebool command is tedious and error-prone by hand — and it’s the single best use of AI for SELinux. Paste the denial:

“Here’s an SELinux AVC denial from ausearch. Explain in plain English what was blocked and why, then give me the least-privilege fix: prefer a boolean or a file-context relabel over a custom policy module. Do not suggest disabling SELinux.”

That last line matters — left unconstrained, models also reach for setenforce 0. With the constraint, they reliably produce the right semanage fcontext or setsebool command. I keep this in my Linux prompts. It’s the same read-and-reason discipline I use for incident triage: AI decodes the log, you run the fix.

The last resort: a custom policy module

When no boolean or context fits, audit2allow builds a targeted module:

sudo ausearch -m avc -ts recent | audit2allow -M myapp_policy
sudo semodule -i myapp_policy.pp

But this is genuinely last-resort. Read the generated .te file before installing it — audit2allow blindly allows whatever was denied, including things you actually want blocked. This is exactly where AI helps: paste the .te and ask “is this policy too broad? Does it grant anything dangerous?” Don’t semodule -i a machine-generated policy you haven’t reviewed.

A note on AppArmor

On Debian/Ubuntu the equivalent is AppArmor, which is path-based and simpler. Check status with sudo aa-status, find denials in journalctl -k | grep apparmor, and put a profile in complain mode with sudo aa-complain /path/to/profile while you debug. The same principle holds: fix the profile, don’t disable the framework. AI translates AppArmor denials just as well.

The takeaway

A SELinux denial is a three-question diagnosis: wrong context, off boolean, or unregistered port. Use permissive mode only to confirm, then fix it properly with semanage/setsebool and return to enforcing. Let AI decode the AVC and produce the least-privilege command — explicitly telling it never to disable SELinux — and always review any generated policy module yourself. Keep the seatbelt on; it’s there for the crash you don’t see coming.

AI-suggested SELinux fixes are assistive. Review generated policy modules and verify commands against your own system before applying.