Forem: Mattia Bandini

SELinux AVC denied: stop guessing, start fixing

Mattia Bandini — Fri, 17 Apr 2026 15:17:49 +0000

It happens more often than not. A web server gets installed, maybe a database, or perhaps a fresh Podman container. Settings are adjusted carefully, one by one. For testing, permissions shift to 777 — though never on live systems — yet somehow the error persists: Permission denied.

There it is — buried in the logs. That overwhelming chunk of text from SELinux stares back:

type=AVC msg=audit(1612345678.123:456): avc:  denied  { read } for  pid=1234 comm="nginx" name="index.html" scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

Right now, many people online suggest simply typing setenforce 0 or turning off SELinux through /etc/selinux/config without thinking twice. While that might stop the error fast, it weakens system security just to fix a configuration issue. Instead of removing protection entirely, learning what triggered the denial helps find safer fixes.

Some opt for quick workarounds when logs show repeated denials. Yet skipping analysis often leads to broader risks later on. Adjusting policies carefully beats disabling them outright. A temporary bypass may seem helpful — until something else breaks silently.

Here’s something worth considering: turning off SELinux strips away critical protection. When it comes to system safety, removing safeguards rarely helps. Rather than silencing warnings, understanding them makes more sense. Think about it: security tools are there for a reason. What if we focused on interpreting alerts instead? That shift could make all the difference.

The Anatomy of an AVC Denial

Imagine a doorkeeper who ignores names, focusing solely on wristbands. That is SELinux — it disregards regular user access levels entirely. Instead, what matters are assigned tags known as Contexts. Entry depends not on identity but on these specific markers. Rules follow the label, never the person behind it.

Here is what the confusing log actually means:

comm="nginx": A single process moves forward, attempting an action under the name nginx. Like a guest approaching a restricted entrance, it seeks access where entry is controlled.
{ read }: This refers to the operation it aimed to carry out.
name="index.html": This is the target file or object.
tclass=file: Indicates what kind of target is being referenced — could be a regular file, a folder, or even a communication endpoint on a network. Each type changes how operations are applied during processing.
scontext=...:httpd_t:... (Source Context): A process running nginx carries a specific identifier. Labelled as httpd_t, it functions much like an access pass for a visitor. The scontext value reflects what the system sees when checking permissions. Considered part of SELinux enforcement, this tag controls how the process interacts with resources. Assigned automatically, the label determines allowed actions within security policies.
tcontext=...:user_home_t:... (Target Context): A person enters a space only if they meet certain conditions — this file needs approval just like that guest. Access depends on meeting specific criteria, much like an exclusive area allowing entry under set terms. The tag given to index.html acts as such a gatekeeper, determining who fits inside.

The Translation: Not allowed. A web server process attempted to open index.html marked as personal user data. Security policy blocked it immediately. Home areas stay off-limits to public-facing services by design. Reading such files breaks containment rules. The system enforces strict boundaries between service roles and private spaces. Permission revoked based on labeling mismatch alone.

Slow Fixes Take Time

Most of the time, system administrators handle this issue by searching semanage fcontext documentation page by page. Another path is feeding the log data into audit2allow for interpretation.

Most people misunderstand what audit2allow actually does: it won’t repair incorrect file labels. Instead, it creates a tailored policy enabling the web server access to home folders. That approach weakens SELinux instead of strengthening it. Usually, the right move involves adjusting the file context through restorecon or chcon. Altering system-wide policies rarely makes sense.

The Fast Way: selinux-explain

One day, it just became too much — reading through audit.log by hand, hunting down the right restorecon or boolean tweaks for messed-up labels. Tools such as setroubleshoot help, true, yet they bring along Python processes and D-Bus connections. My stripped-down, isolated systems do not run those.

A small program took shape: selinux-explain — crafted fully in Rust, running without internet. It works through your terminal, staying fast by design. Built to explain SELinux rules locally, it avoids external dependencies. No cloud needed, just direct responses from your machine.

Most times, people guess what went wrong — here, denied logs go straight in. Once inside, each refusal gets broken down, clear as speech anyone understands. A reason appears without jargon, showing exactly why access failed. From there, a precise instruction forms, tailored to resolve the issue safely.

Key Features

Single static binary: No external libraries required during operation. Runs independently of system-installed components. Entire program contained within a single output. Does not rely on additional software at execution time.
Offline by default: Works without internet access — ideal for protected networks where external connections are restricted.
Context-aware: Because it recognizes patterns, containers get the :Z flag automatically. Web services often require specific permissions — this adjusts them without extra steps. For instance, when a server needs network access, the system enables it through policy changes. Knowing typical setups helps avoid common roadblocks. Configuration follows real-world usage rather than rigid rules. Each decision builds on what the environment actually does.
Extensible: Powered by a community-driven rules.toml file.

Try it out

You can grab the pre-compiled binaries for your architecture on the GitHub Releases page.

When SELinux stops your app, skip typing setenforce 0. Instead, send the log through selinux-explain — watch how it decodes the message silently. Each error finds clarity without disabling security layers first.

Should you come across a rare scenario the tool fails to identify, consider submitting a pull request. Alternatively, apply the --report option to contribute toward growing its collection of rules.

I got tired of setenforce 0. So I built a tool in Rust to actually understand SELinux denials.

Mattia Bandini — Thu, 02 Apr 2026 21:46:05 +0000

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:

type=AVC msg=audit(1612345678.123:456): avc: denied { read } for pid=1234 
comm="nginx" name="index.html" dev="sda1" ino=12345 
scontext=system_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0

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.

What it does

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:

🚨 SELinux Denial Detected!
=============================

Who:  nginx
What: Tried to 'read' the target 'index.html'
Why:  A process with label 'httpd_t' is not allowed to access 
      objects with label 'user_home_t'

💡 Suggestion:
The web server is trying to read a file or directory labeled 'user_home_t'.
Fix its context with: `sudo restorecon -Rv </path/to/index.html>`
Or set it manually: `sudo chcon -t httpd_sys_content_t </path/to/index.html>`

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:

Analyze the latest denial in your system log

sudo selinux-explain --last

Analyze a specific log line

selinux-explain --text "type=AVC msg=audit..."

Pipe directly from the audit log

grep nginx /var/log/audit/audit.log | selinux-explain

Why Rust

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.

How it's built

The architecture is straightforward — four modules:

parser.rs is the core. It takes a raw log line and extracts the relevant fields using a regex:

rustlet re = Regex::new(
    r#"denied\s*\{\s*(.*?)\s*\}.*?comm="(.*?)".*?name="(.*?)"
    .*?scontext=(\S+).*?tcontext=(\S+).*?tclass=(\S+)"#
).ok()?;

The result is an AvcData struct:

rustpub struct AvcData {
    pub process: String,
    pub action: String,
    pub target: String,
    pub scontext: String,
    pub tcontext: String,
    pub tclass: String,
}

explainer.rs takes an AvcData and produces a human-readable explanation. The interesting part is get_specific_advice(), which matches on a tuple of (source_type, action, tclass) to give contextual suggestions:

rustmatch (source_type, action, tclass) {
    ("httpd_t", "read" | "open" | "getattr", "file" | "dir") => {
        // web server trying to read a file with wrong label
    },
    ("httpd_t", "name_connect", "tcp_socket") => {
        // web server trying to make outbound network connection
    },
    ("container_t", _, _) => {
        // container trying to access host resource
    },
    _ => {
        // generic fallback
    }
}

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.

reader.rs handles reading from /var/log/audit/audit.log for the --last flag — it scans the file line by line and returns the most recent AVC denial.
main.rs ties everything together with clap for argument parsing, and handles the three input modes: --last, --text, and stdin pipe detection via io::stdin().is_terminal().

The reception

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."

What's next

The immediate roadmap:

rules.toml support — an external file that maps (source_type, action, tclass) tuples to suggestions, so the community can contribute new cases without needing to know Rust
RPM package and COPR repository — once the tool is stable enough, proper distro packaging for Fedora and RHEL
More covered types — mysqld_t, sshd_t, smbd_t are next on the list

Try it

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.