A service on a RHEL host is failing and the audit log shows an SELinux AVC denial. Walk through how you decide between correcting a label, flipping a policy boolean, and generating a custom policy module — and say what it could mean when the denial you expect never appears in the log at all.

## Read the record before you touch anything An AVC denial is a complete statement of the question the kernel asked and the answer it gave. The fields that matter: - `avc: denied { read }` — the permission requested, on the object class named by `tclass`. - `scontext=...:httpd_t:s0` — the subject: which domain the calling process was in. - `tcontext=...:user_home_t:s0` — the object's label. - `tclass=file` — the object class: file, dir, tcp_socket, unix_stream_socket, capability, and so on. Those four values usually diagnose the problem on their own. `httpd_t` denied `read` on a `user_home_t` file is a labelling problem. `httpd_t` denied `name_connect` on a database port type is a boolean or a port-label problem. `httpd_t` denied a capability is a much bigger conversation about what the application thinks it needs. `ausearch -m AVC -ts recent` pulls the recent records, and `audit2why` explains a denial in prose, including telling you when a boolean would have permitted it — which is often the fastest route from record to fix. ## The ladder, in order of preference **1. Is the target labelled correctly?** This is the most common cause by a wide margin, because labels ride on inodes and data gets moved, restored from backup, or written into a path the policy has no rule for. If the type in `tcontext` is not what that path should have, fix the label — with a `semanage fcontext` rule where the path is non-standard — and the denial disappears without any policy change at all. Nothing has been weakened. **2. Is there a boolean for this?** SELinux policy ships with named tunables covering behaviours that are legitimate for some deployments and not others: whether the web server may make outbound network connections, whether it may write to particular content, whether a daemon may read user home directories. `getsebool -a` lists them all with their current values; `semanage boolean -l` adds a description column. Enable with `setsebool -P <boolean> on` — the `-P` is what makes it survive a reboot, and forgetting it produces the classic "it worked until the machine restarted" incident. A boolean is a change the policy author anticipated and scoped, which makes it far safer than a rule you write yourself. **3. Does the application genuinely need an access the policy does not model?** Only now do you write policy. The method matters: ```bash semanage permissive -a myapp_t # confine nothing for this one domain # exercise the application fully ausearch -m AVC -ts recent | audit2allow -M myapp_local cat myapp_local.te # READ THIS semodule -i myapp_local.pp semanage permissive -d myapp_t ``` Two things make this professional rather than reckless. First, running the domain permissive means the application does not die at its first denial, so you collect the *whole* set of accesses rather than fixing them one reboot at a time. Second, `audit2allow` output is a draft, not an answer: it converts observed denials into allow rules mechanically, and if the application misbehaved during collection — or if an attacker's probe was in the log — those accesses get blessed too. Rules granting broad permissions on `capability`, or write access to a system type, are the ones to challenge. ## When the denial is not there Some denials are deliberately silenced. Policy contains `dontaudit` rules for accesses that programs routinely attempt and do not need, so the logs are not drowned in noise. The consequence is that a real failure can produce no visible denial at all. Rebuild the policy with suppressions disabled to see them: ```bash semodule -DB # disable dontaudit rules and rebuild # reproduce the failure, read the log semodule -B # rebuild normally again ``` Always put it back. The other explanations for a missing record are more mundane and worth ruling out first: `auditd` not running (denials then land in the kernel ring buffer and the journal instead of `/var/log/audit/audit.log`), rate limiting under a flood of identical records, or the AVC cache — a repeated identical access can be answered from cache without generating another log line, which is why counting occurrences in the log understates how often it happened. ## The two anti-patterns Switching the machine to permissive, or disabling SELinux, converts a specific containment failure into a general loss of containment, and it usually gets forgotten until an audit finds it. Blanket-installing an unread `audit2allow` module does the same thing more quietly, because the resulting grant is invisible unless someone reads the module. In both cases the honest interview answer is that the fix must be as narrow as the problem: relabel one path, or flip one boolean, or install a module whose rules you can defend line by line.