explaingit

azqzazq1/lid

Analysis updated 2026-06-24

12CAudience · researcherComplexity · 5/5LicenseSetup · hard

TLDR

Security write-up of three Linux kernel paths (eBPF, io_uring MSG_RING, new mount API) that perform sensitive actions without invoking LSM hooks, hiding from AppArmor and audit.

Mindmap

mindmap
  root((LID))
    Inputs
      Linux kernel internals
      LSM framework
    Outputs
      Three findings write-up
      Reproducibility matrix
      Quick reference table
    Use Cases
      Red team research
      AppArmor policy review
      SIEM detection gap audit
    Tech Stack
      C
      eBPF
      io_uring
      AppArmor
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

What do people build with it?

USE CASE 1

Audit your AppArmor or SELinux policy against the three documented LSM visibility gaps

USE CASE 2

Reproduce LID-001 eBPF pathname rewriting against an AppArmor profile in a lab

USE CASE 3

Test whether your EDR detects io_uring MSG_RING file descriptor passing

USE CASE 4

Cite the Zenodo write-up in red team research on Linux integrity

What is it built with?

CeBPFio_uringAppArmor

How does it compare?

azqzazq1/lidatc1441/atc_rtl_ble_oeplkernelstub/exptemp
Stars121212
LanguageCCC
Setup difficultyhardhardmoderate
Complexity5/55/54/5
Audienceresearcherops devopsresearcher

Figures from each repo's GitHub metadata at analysis time.

How do you get it running?

Difficulty · hard Time to first run · 1day+

Reproducing the findings needs matching kernel versions, configs, and capabilities listed in the reproducibility matrix.

MIT license, so you can use, modify, and ship it with almost no restrictions as long as you keep the copyright notice.

In plain English

LID stands for Linux Integrity Drift, and the repository is a security-research write-up of three kernel code paths in Linux that perform security-sensitive operations without consulting the Linux Security Module (LSM) framework. The LSM framework is the layer that AppArmor, SELinux, Smack, and similar tools plug into to enforce policy. The author's point is not that LSM itself is broken, but that some kernel subsystems do work that should pass through LSM hooks and quietly do not, so the policy engine never sees the action. The README is careful to separate two questions about each finding. The first is the policy visibility gap: what AppArmor or SELinux actually sees, what the audit log records, and what a SIEM or EDR can observe. The second is the practical escalation path: whether the issue lets an attacker cross a privilege boundary, or whether the attacker already needs root or a specific capability. The author argues these are different things, and a finding can be a serious visibility gap even when it does not by itself grant new privilege. Three findings are documented. LID-001 uses an eBPF kprobe to rewrite a filename argument before AppArmor's path-based check runs, so AppArmor evaluates the wrong path, it needs root or CAP_BPF plus CAP_PERFMON. LID-002 uses io_uring's MSG_RING with SEND_FD to pass a file descriptor in a way that skips security_file_receive(), and notably this one works from unprivileged userspace. LID-003 uses the newer mount API (fsopen and fsmount) which the author says never calls security_sb_mount(), making AppArmor's mount policy unenforceable on that path, it needs CAP_SYS_ADMIN in a user namespace. A reproducibility matrix lists the exact kernel versions, kernel configs, privilege levels, lockdown modes, sysctls, and target LSM for each finding. A quick reference table shows which findings work on Ubuntu, Debian, RHEL/Fedora, locked-down systems, unprivileged users, and containers. SELinux is noted as not vulnerable to LID-001 or LID-003 because it is inode-based rather than path-based. The project is MIT licensed and has a Zenodo DOI for the write-up. The README ends mid-section on the LID-001 deep dive in the clip shown here.

Copy-paste prompts

Prompt 1
Summarise the three LID findings and which one works without root
Prompt 2
Explain the io_uring MSG_RING SEND_FD path that skips security_file_receive
Prompt 3
Write a detection rule sketch for SIEM that would catch LID-002 attempts
Prompt 4
Compare LID-001 against SELinux versus AppArmor and explain why SELinux is not vulnerable

Frequently asked questions

What is lid?

Security write-up of three Linux kernel paths (eBPF, io_uring MSG_RING, new mount API) that perform sensitive actions without invoking LSM hooks, hiding from AppArmor and audit.

What language is lid written in?

Mainly C. The stack also includes C, eBPF, io_uring.

What license does lid use?

MIT license, so you can use, modify, and ship it with almost no restrictions as long as you keep the copyright notice.

How hard is lid to set up?

Setup difficulty is rated hard, with roughly 1day+ to a first successful run.

Who is lid for?

Mainly researcher.

Open on GitHub → Explain another repo

This repo across BitVibe Labs

Verify against the repo before relying on details.