Stop guessing why your custom binary is failing under SELinux

Technical Briefing | 9/25/2026

Every time I roll out a custom Go binary to production, there is that split second of dread where I wonder if SELinux is going to kill it instantly. You set up your service unit, you point it at your binary in opt, and then the logs show nothing but a cryptic permission denied error. It is not always the binary’s fault, and hitting setenforce 0 just to see if it works is a dangerous habit that keeps you from actually fixing the problem.

Why your binary acts like a stranger to the kernel

The kernel denies execution because the security context on your file does not match what the policy expects. Most people try to fix this by blindly applying labels, but that is a quick way to create a security hole. Instead, watch the audit logs in real time while you trigger the failure. This tells you exactly which context is missing so you can map it properly.

tail -f /var/log/audit/audit.log | grep avc | grep denied

• Use restorecon -v to check if the file system labels match the current policy definition
• Check matchpathcon to see what the system thinks the label should be before you force a change
• Always write a custom local module if your binary needs non-standard network access instead of disabling policies

Once you identify the AVC denial, use audit2why to get a human-readable explanation of why the kernel blocked you. If the logic checks out and your binary really needs that socket or path, use audit2allow to generate the fix. Just remember that it is just a tool, not a genius; review the generated policy before you run semodule -i on it, or you might accidentally permit way more than you intended.

Next time you are staring at a binary that refuses to start, don’t reach for the permissive switch. Keep the audit log open on one screen and iterate. You will learn more about how your system enforces isolation in five minutes of parsing logs than you would from reading the entire SELinux user guide.