🛡️ Fixing SELinux Denials Without Setting Permissive: A Least-Privilege Approach

There is a reflex, hardwired into a generation of Linux administrators, that the first response to any SELinux denial is setenforce 0. It makes the error go away in seconds, which is exactly why it is so dangerous: it also throws away one of the strongest containment layers a Linux host has, often permanently, because “temporarily permissive” has a way of becoming permanent. The truth is that the overwhelming majority of SELinux denials are not policy bugs at all — they are mislabeled files or a boolean that needs flipping, and both have surgical fixes that keep the system enforcing. This guide is about reaching for the scalpel instead of the off switch.

Read the Denial Before You React to It

Every SELinux denial is logged as an AVC (Access Vector Cache) message, and it tells you precisely what was blocked if you slow down to read it:

type=AVC msg=audit(1718000000.123:456): avc:  denied  { write } for
  pid=2841 comm="nginx" name="upload.tmp" dev="sda1" ino=98231
  scontext=system_u:system_r:httpd_t:s0
  tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0

Decoded: the httpd_t domain (nginx) tried to write a file labeled default_t, and was denied. The signal is in the type mismatch — nginx writes files labeled httpd_*_t, and this file is default_t, which means the file is mislabeled, not that nginx lacks a legitimate permission. The ausearch -m AVC -ts recent and sealert tools render this more readably, but the structure is always the same: a source domain, an action, a target type, and a class.

Most Denials Are One of Three Root Causes

Once you can read the AVC, denials sort into three buckets, and the bucket determines the fix:

1. Wrong file or port context — a resource is labeled with the wrong type. The fix is a relabel, not a policy change. This is by far the most common case.
2. A boolean that needs setting — the policy already supports the behavior, it is just gated behind a tunable that is off. The fix is one setsebool.
3. A genuinely missing rule — the policy does not allow this legitimate behavior at all. This is the rare case that needs a custom module.

The discipline is to work down that list. Reach for a custom policy module only after ruling out the first two, because a module is the heaviest, most error-prone fix and the easiest to over-scope.

The Surgical Fixes

For the mislabeled file above, you fix the label and make it stick across relabels:

# Tell the policy how this path should be labeled, then apply it
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/uploads(/.*)?"
sudo restorecon -Rv /var/www/uploads

Using semanage fcontext plus restorecon — rather than a raw chcon — is what makes the label survive a future filesystem relabel. A non-default port follows the same shape with semanage port. For the boolean case, you find the relevant tunable and set it persistently:

# Discover the boolean that gates the behavior, then enable it permanently
sudo semanage boolean -l | grep httpd_
sudo setsebool -P httpd_can_network_connect on

The -P makes it persist across reboots. Between contexts and booleans, you have resolved the large majority of real-world denials without ever touching enforcement.

When You Genuinely Need a Custom Module

Sometimes the behavior is legitimate and no boolean or label covers it. Here audit2allow is the standard starting point — and “starting point” is the operative phrase, because audit2allow will happily generate a module that grants far more than the specific denial required:

# Generate a candidate module from the denials — then READ AND TRIM IT
sudo ausearch -m AVC -ts recent | audit2allow -M myapp_local
# This produces myapp_local.te (the rules) and myapp_local.pp (the compiled module).
# Open the .te file, justify every single rule, and delete anything broader than needed.
cat myapp_local.te

The mistake teams make is loading the .pp straight from audit2allow without reading the .te. If audit2allow saw a denial for one specific operation but the generated rule grants a broad set of permissions on a wide type, you have just punched a much bigger hole than the problem warranted. Every line in that file should map to a denial you understand and a behavior you can justify. This is the same trim-and-justify discipline that good seccomp and AppArmor profiles demand — generated baselines are drafts, not finished policy.

What to Do Mid-Incident

The honest answer to “but the app is down right now” is not global permissive. If you must unblock immediately while you diagnose, make a single domain permissive rather than the whole system, and put a reminder on its removal:

# Make ONLY this domain permissive, not the entire host — and undo it once fixed
sudo semanage permissive -a httpd_t
# ... diagnose and apply the real least-privilege fix ...
sudo semanage permissive -d httpd_t   # remove it; back to enforcing for this domain

This contains the loosening to one application’s domain instead of disabling containment host-wide, and it is reversible per-domain. Global setenforce 0 is never the fix — at most it is a brief, logged, explicitly time-boxed step, and even then the per-domain approach is almost always better.

Let AI Decode, Not Decide

AVC messages are terse and the fix depends on correctly classifying the root cause, which is a good fit for an LLM as a decoder and first-pass diagnostician:

Prompt: “Decode these SELinux AVC denials in plain English: which domain tried which action on which target type. Classify each as wrong-context, missing-boolean, or needs-custom-module. Give the least-privilege fix — prefer semanage fcontext/port or setsebool over a custom module. Do NOT recommend setenforce 0 or global permissive. If a module is truly needed, justify every rule and flag anything broader than the denial.”

Output (excerpt): “Denial 1: httpd_t denied write on a default_t file — root cause: wrong file context (mislabel), not a policy gap. Fix: semanage fcontext -a -t httpd_sys_rw_content_t on the path, then restorecon. No module needed. Denial 2: httpd_t denied name_connect to a remote port — root cause: missing boolean. Fix: setsebool -P httpd_can_network_connect on. Verify both in enforcing mode and confirm no new denials appear.”

The model is good at the decode-and-classify step that intimidates people into reaching for the off switch. But you apply the fix, confirm it in enforcing mode, and own any custom module — the AI drafts, you verify. If you want a structured pass over a pile of denials, the SELinux troubleshooting prompt decodes each AVC, classifies the root cause, and produces the minimal fix without ever recommending you disable enforcement.