SELinux Troubleshooting: From AVC Denial to Root-Cause Fix

SELinux denials wear a disguise: the application reports a plain Permission denied, but the file's owner, group, and mode all look correct. That mismatch — DAC says yes, the app says no — is the tell. A web server that can read /var/www/html but returns 403 for a page you moved in from your home directory; a service that won't bind a non-standard port; a container that can't write a volume — all classic SELinux, not Unix permissions.

The reason is that SELinux is Mandatory Access Control layered on top of discretionary permissions. Even after the mode/owner check passes, the kernel consults the policy: does the process's type (its domain) have permission to act on the target's type? If not, it's denied and — in enforcing mode — logged as an AVC (Access Vector Cache) denial. Your job in troubleshooting is to turn that denial into a specific, minimal fix rather than the reflexive setenforce 0 that disables the whole protection.

Before you spend time chasing labels, prove SELinux is actually the culprit. Permissive mode applies the policy in name only: it logs what it would deny but allows everything. So if a failure disappears in permissive and returns in enforcing, SELinux owns it.

AVC denials are written by the kernel and captured by auditd in /var/log/audit/audit.log. Don't grep that file by hand — ausearch filters it for you, and -ts (time-start) narrows to the window you care about.

On a system with setroubleshoot installed, sealert -a /var/log/audit/audit.log (or the desktop alert) translates each denial into plain English and suggests candidate fixes — a useful cross-check, though you should still understand the fix before applying it.

A context is user:role:type:level. For troubleshooting, the type (the _t field) is almost always what matters. In the example above the source type is httpd_t (the web server's domain) and the target type is user_home_t — a file still labelled as if it lived in someone's home directory. The policy simply has no rule letting httpd_t read user_home_t, so: denied.

Read it as a sentence: 'a process of type `httpd_t` was denied `read` on a `file` of type `user_home_t`.' Once you can say that sentence, the fix follows from which half is wrong — the target's label, or the policy that governs the source.

To decide quickly whether a label is wrong, compare the file's actual context against the default the policy expects for that path. matchpathcon /var/www/html/report.html (or the newer selabel_lookup) prints what the label should be; if that differs from what ls -Z shows, you have a relabel problem and the fix is restorecon, not a boolean or a module. When the actual and expected already agree yet access is still denied, the label is fine and you move on down the tree — the cause is a boolean, a port, or a genuine policy gap. Building that actual-versus-expected reflex is what separates a five-minute fix from an afternoon of guesswork.

Almost every denial resolves to one of four causes — check them in this order:

1. Wrong file label (most common). The target's type doesn't match its location/role. Fix by relabelling: restorecon (restore the default) or semanage fcontext (define a new default) then restorecon.

2. A boolean is off. The policy already supports what you want, but it's gated behind a tunable — e.g. httpd_can_network_connect. Fix with setsebool -P.

3. A non-standard port. A daemon is binding a port the policy doesn't associate with its type (name_bind on a tcp_socket). Fix with semanage port -a.

4. A genuine policy gap. Nothing above fits and the action is legitimately novel. Only now consider a custom module via audit2allow.

If the file simply has the wrong label for where it lives, restorecon resets it to the policy's default for that path. If you've put content in a new location the policy doesn't know about, first teach the policy the default with semanage fcontext, then apply it with restorecon.

When the label is right but the policy still says no, a boolean usually gates the behaviour. List candidates with getsebool -a | grep httpd (or semanage boolean -l for descriptions), then set persistently with -P. For a daemon on a non-standard port, register the port with the daemon's port type.

Only when the denial is genuinely new — no label, boolean, or port fits — do you build a custom module. ausearch -m avc -ts recent | audit2allow -M mymodule generates a .te/.pp from the logged denials; semodule -i mymodule.pp installs it. Read the generated rules first. audit2allow will happily grant whatever was denied, including denials caused by a compromise or a wrong label you should have fixed instead. It is the tool of last resort, not the first.

The Signal9 SELinux labs hand you denials as saved AVC records (/root/case/avc.log) on a box whose kernel runs with SELinux disabled. Nothing is enforced live, so the work is the part that persists: the policy store that an enforcing box loads at boot. Three tools carry that work, and each takes the policy file explicitly when there is no live kernel policy to ask.

`audit2why` reads an AVC and tells you which branch of the decision tree it is on. Point it at the on-disk policy with -p and at the log with -i.

`semanage permissive` is the scoped version of the permissive probe from step 2. Instead of setenforce 0, which drops protection for every service, it makes one domain permissive: that process's denials are logged but allowed, and everything else stays enforced. You need the domain (the process type, like squid_t), not the type of its binary on disk (squid_exec_t). matchpathcon on the binary gives you the exec type, and the domain is usually the same name ending in _t.

Prove the change persisted. semanage writes every fix (file-context rules, port labels, booleans) to the policy store, and adding -C lists only the local customizations, which is exactly what your fix changed. It's the quickest check that you changed one thing and not three.