Don’t just audit2allow your SELinux problems away

Technical Briefing | 9/20/2026

Most of us have been there: SELinux is on, it’s blocking your shiny new custom app or script, and audit.log is filling up with AVC denials. You fire up audit2allow, generate a policy module, load it, and boom — it works. Crisis averted, right? Well, maybe for five minutes. I’ve seen this silently fail to hold up to the next package upgrade, or worse, open up a gaping hole because the auto-generated rules were way too broad. It’s a quick fix, sure, but it’s a crutch, not a solution.

The audit2allow Convenience Trap

Look, I’m not saying audit2allow is evil. It’s fantastic for identifying what’s blocking you in a pinch, or for quickly getting a proof-of-concept off the ground. But relying on it for production systems is where you run into trouble. It often takes a specific denial, like a process trying to write to /var/www/html/mydata, and turns it into a generic rule that says ‘this process can write anywhere labeled httpd_sys_content_t’. And that’s usually not what you want. It papers over the cracks without actually understanding why SELinux was blocking it in the first place, or what the correct context should have been.

Beyond the Denial: Understanding Policy

When SELinux blocks something, it’s not just randomly breaking your day. It’s enforcing a specific policy. An AVC denied message in your audit logs, which you can usually find with ausearch -m AVC -ts today, tells you a lot: the source context of the process, the target context of the file or resource, the class (like file or socket), and the specific permission denied (read, write, execute). The goal isn’t just to make the denial go away; it’s to give your application just enough permissions to do its job, and no more. That often means assigning custom contexts.

This is where semanage fcontext and restorecon come into play. semanage fcontext lets you define rules for how files and directories should be labeled by default based on their path. You’re telling SELinux, ‘Any file in this directory should have this specific type label.’ Then restorecon -Rv actually applies those labels to the files on disk, ensuring they match your defined policy. It’s like telling SELinux, ‘This part of the filesystem is special; treat files here like X, not like Y.’ This is miles better than globally allowing a process to do things it shouldn’t just because it touched one file in a weird spot.

semanage fcontext -a -t mydaemon_log_t "/var/log/mydaemon(/.*)?"
restorecon -Rv /var/log/mydaemon
# Now you'd write a policy for mydaemon to allow writes to mydaemon_log_t
# audit2allow -l -M mydaemon_local_log if it's still blocking AFTER context is set
# then look at the generated .te to see if it's too broad or just right.

• Always define a specific type for custom application data (logs, config, data dirs) using semanage fcontext.
• Regularly run restorecon -Rv on application directories, especially after deploying new files or upgrades.
• Check existing contexts with ls -Z or ps -Z to understand what SELinux sees.
• When troubleshooting, use auditd logs (ausearch) to identify exact source, target, class, and permissions.
• Only use audit2allow to propose initial rules, then carefully review and refine the generated .te file before compiling and loading.

Yeah, this takes more thought than just running audit2allow blindly. But the payoff is a system that’s actually more secure and less prone to unexpected breakages when something changes outside the scope of your initial quick fix. You’ll build a much clearer picture of your application’s true SELinux footprint, and you won’t be scrambling to understand why your service suddenly stopped working after a yum update changed some underlying package’s policy. The right approach here is to understand the policy, define your contexts, and then tailor your local policy, not just patch over symptoms.