Re: [RFC/Discussion] eBPF-based runtime permission auditing tool for SELinux policies

On Mon, Aug 17, 2026 at 3:18 PM rushikesh ghatpande
<[email protected]> wrote:
>
> Hi all,
>
> I've been working on a small tool that uses eBPF to observe SELinux
> AVC decisions at runtime and flag unused permissions within existing
> allow rules. The idea is to help identify over-permissive policy that
> audit2allow-style workflows tend to leave behind, since they only ever
> add permissions and rarely surface which granted permissions are
> actually exercised.
>
> Repo:
> https://github.com/rushigerrard8/selinux-policy-auditor
>
> Briefly, how it works:
>
> - Hooks into the LSM layer via eBPF (BCC) to observe AVC checks for a
> given context, without modifying the running policy (no auditallow
> needed)
> - Aggregates observed permission usage over a monitoring window
> against the policy's existing allow rules
> - Reports the unused subset per rule, e.g. an app granted { read write
> append create unlink open } on a file class where only { read open }
> were ever exercised
>
> I built this mainly to solve a problem I kept hitting in my own work
> on distributed systems/networking (permission creep in service
> policies over time), and it's been useful enough that I wanted to
> bring it to this list for feedback, rather than just leave it as a
> personal tool.
>
> A few things I'd appreciate input on:
>
> 1. Whether this overlaps with existing tooling I'm not aware of (I
> know setroubleshoot/audit2why cover related but not identical ground)
> 2. Whether there's interest in something like this living closer to
> the userspace toolchain, or if it's better as a standalone project
> 3. Any gaps in my approach. I'm relying on kernel-level PID filtering
> to keep overhead low, but I haven't stress-tested it against
> high-throughput services yet

Thanks for sharing this. I'm not aware of existing tooling that
overlaps with this.
We have in the past discussed doing this kind of thing via auditallow
rules and Android has used those at times for a very selective form of
this, but that approach doesn't scale well.
If others find it to be useful and it is well-maintained, we could
consider adding it to the SELinuxProject GitHub in the future, either
as its own repo or as an addition to the selinux userspace tree.
Whether or not the latter would be best likely depends on how tightly
coupled it is to other components in the selinux userspace.