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

rushikesh ghatpande <[email protected]>
Newsgroups org.kernel.vger.selinux
Message-ID <CAG94myvBHohDtG4kNdMNYzYOBYAZ9-tcKPpiJb_T7bb1fuE0_Q@mail.gmail.com>
Hi Stephen,

Thank you for taking a look, and for the context on the
auditallow/Android precedent. It is a helpful confirmation that the
runtime-observation angle is worth pursuing via a different mechanism.

It would be an honor to have this considered for the SELinuxProject
GitHub. I'd also like to be an active contributor to the SELinux space
more broadly, not just with this one tool. I see this as a starting
point.

On coupling: the eBPF side hooks avc_has_perm(), plus a few more
targeted LSM hooks (selinux_file_open, selinux_mmap_file,
selinux_inode_getattr). This is done via BCC. There's no dependency on
libselinux, libsepol, or policycoreutils here.

On the policy side, it currently shells out to sesearch (setools) to
extract allow rules for a given context. So there is a dependency on
setools, but not on the core userspace tree itself.

Given that, I'd lean toward a standalone repo for now. It sits next to
the existing tree, not inside it. I'm open to your view on where the
right boundary is.

I'm happy to keep improving it based on feedback. If there's anything
specific you'd like me to change or look at, let me know.

Thanks & Regards,
Rushikesh Ghatpande

On Tue, Aug 18, 2026 at 9:01 AM Stephen Smalley
<[email protected]> wrote:
>
> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.