Tools
Tools: LID / Linux Is Dying - Expert Insights
I Bypassed AppArmor Without Disabling It — Using eBPF
The Setup
The Technique
The Result
Why BPF LSM Can't Do This
The Architecture
Stealth
The Bigger Picture
Limitations
Try It
What This Means The Linux Security Module framework has one iron rule that has held for 20+ years: Security modules can only add restrictions. They can never remove them. I didn't break that rule. I walked around it. AppArmor is a mandatory access control (MAC) system used on Ubuntu, Debian, SUSE, and most enterprise Linux distributions. It confines processes to a set of allowed file paths, network access, and capabilities. Here's a simple AppArmor profile: This says: test_reader can read anything in /tmp/ except secret_test_file.txt. AppArmor is doing its job. The kernel's LSM framework iterates every security module, and AppArmor says no. Game over. I wrote a BPF kprobe that attaches to do_sys_openat2 — the kernel's internal file-open handler. It fires before the kernel copies the filename from userspace. At that point, the filename is still sitting in a writable user-space buffer. The trick: I created a hard link to the secret file at a path AppArmor allows: AppArmor is pathname-based — not inode-based like SELinux. Two hard links to the same file are completely different identities to AppArmor. The deny rule blocks /tmp/secret_test_file.txt but the permissive /tmp/** r rule allows /tmp/.aa_bypass_link. The BPF kprobe rewrites the path before the kernel copies it → AppArmor checks the allowed path → grants access → process reads the protected file's content. AppArmor was never defeated. It was deceived. It correctly enforced its policy — on the wrong path. You might think: "Just use BPF LSM to override AppArmor." I tried. It can't. The kernel's call_int_hook macro iterates LSM hooks and short-circuits on the first denial: The LSM framework is secure. No module can undo another's denial. But kprobes don't go through the framework. They attach directly to kernel functions and execute before any LSM hook is consulted. Two kernel subsystems. Incompatible trust assumptions. One gap. This isn't just a bypass — it's an invisible bypass: The only artifact is a one-time kernel warning that says a BPF program might write to user memory. It doesn't say what, where, or when. This technique pairs with my earlier research SunnyDayBPF — which manipulates telemetry data after syscalls complete: Combined: ghost access. Bypass the security check, then rewrite what the monitoring system observed. The SIEM sees nothing. The analyst sees nothing. Being honest about what this can't do: The repo includes automated scripts for the complete demo — from AppArmor profile creation to bypass demonstration to cleanup. This isn't a bug in AppArmor. It's not a bug in eBPF. It's a design gap where two kernel subsystems have incompatible trust assumptions: When you can modify the input to a security check, the correctness of the check itself doesn't matter. The gate was never breached. It was misdirected. LID — Linux Integrity Drift
"Linux is Dying" Azizcan Daştan — Milenium Security 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
