Tools: Report: I got tired of setenforce 0. So I built a tool in Rust to actually understand SELinux denials.
What it does
Analyze the latest denial in your system log
Analyze a specific log line
Pipe directly from the audit log
Why Rust
How it's built
The reception
What's next
Try it Every Fedora user has been there. You're setting up nginx, or configuring a custom app, or mounting a Docker volume — and suddenly everything stops working. You check the logs and you find something like this: And your brain just... stops. Most people at this point do one of two things: paste the log on StackOverflow and wait, or run sudo setenforce 0 and forget about it. I've done both. The second option is particularly dangerous because you're disabling the entire SELinux enforcement on your system just because you couldn't read a log line.
There are existing tools — sealert, audit2why, the SELinux plugin for Cockpit. They're useful if you know what you're doing. But they all have friction: sealert requires the setroubleshootd daemon running in the background with D-Bus, audit2why is part of a Python package that isn't always available on minimal or headless servers, and Cockpit requires a full Cockpit setup.I wanted something simpler. A single binary I could drop on any machine — a fresh VPS, an air-gapped server, a minimal Fedora install — and just pipe a log line into it. So I built selinux-explain. selinux-explain takes a raw SELinux AVC denial and turns it into something a human can actually act on.Instead of the wall of text above, you get: Three things: what happened, why SELinux blocked it, and what to actually do about it. No daemon, no internet, no Python. You can use it three ways: I'm a second-year Computer Engineering student at the University of Bologna and Rust is the language I've been learning independently over the past year. This project felt like the right fit for a few reasons.The main one is the deployment model. A Rust binary compiles to a single static executable with no runtime dependencies. You cargo build --release, copy the binary to /usr/local/bin/, and you're done. No Python interpreter, no shared libraries to worry about, no pip install in a system that might not even have pip. For a tool that targets sysadmins on production servers, this matters.The second reason is performance. Parsing log files with regex is fast in any language, but with Rust you also get predictable memory usage and no garbage collector pauses. For a CLI tool that might be piped across thousands of log lines, that's not irrelevant. The architecture is straightforward — four modules: The result is an AvcData struct: This is the "80/20" approach: cover the most common denial types first (httpd_t, container_t) and fall back gracefully for everything else. The plan is to eventually move these rules into an external rules.toml file so the community can contribute new cases without touching Rust code. I posted about this on r/redhat before even having a working version — just a day-0 post asking whether people would find it useful. The response surprised me: over 5K views and 14 comments in the first 24 hours, including a Red Hat employee who commented and pointed out a classic Unix anti-pattern in my example (I was using cat file | grep instead of just grep file — the infamous "useless use of cat"). That kind of immediate feedback from people who actually work with these systems every day is exactly what you want when building a tool like this.Several people pointed out sealert and audit2why as existing alternatives. Fair points — and I addressed them directly in the thread. The positioning isn't "this replaces everything" but "this works everywhere, with zero setup, offline." The immediate roadmap: The repo is at selinux-explain. There's a pre-compiled binary on the Releases page if you don't want to build from source.
If you run into a log line that doesn't parse correctly, open an issue with the raw log string. Every real-world case helps make the parser more robust — and if you have a fix that worked for you for a type that isn't covered yet, I'd love to hear it. The goal is simple: nobody should have to run setenforce 0 because they couldn't read a log file. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse