``` ██╗ ██╗██████╗ ██║ ██║██╔══██╗ ██║ ██║██║ ██║ ██║ ██║██║ ██║ ███████╗██║██████╔╝ ╚══════╝╚═╝╚═════╝ ```

लिनक्स इंटीग्रिटी ड्रिफ्ट

— "लिनक्स मर रहा है" —

LSM सुरक्षा गारंटियों को बायपास करने वाले कर्नेल कोड पथों की व्यवस्थित खोज
_{गेट कभी तोड़ा नहीं गया। इसे बस घूमकर पार किया गया।}

LID क्या है?

लिनक्स सिक्योरिटी मॉड्यूल फ्रेमवर्क की एक मुख्य गारंटी है जो 20+ वर्षों से बनी हुई है:

सुरक्षा मॉड्यूल केवल प्रतिबंध जोड़ सकते हैं। वे कभी भी प्रतिबंध हटा नहीं सकते।

यह गारंटी सही है। LID इसे तोड़ता नहीं है।

LID ऐसे कर्नेल कोड पथ ढूंढता है जो LSM हुक को पूरी तरह से बायपास करते हैं — वे सबसिस्टम जो LSM फ्रेमवर्क से परामर्श किए बिना सुरक्षा-संवेदनशील संचालन करते हैं। सुरक्षा जांच सही है। समस्या यह है कि कर्नेल कभी पूछता ही नहीं।

यह समझना कि LID क्या है (और क्या नहीं है)

प्रत्येक खोज के दो अलग-अलग आयाम हैं जिन्हें भ्रमित नहीं किया जाना चाहिए:

A) नीति दृश्यता अंतर

वास्तुशिल्पीय अंध-स्थान। सवाल यह नहीं है कि "क्या कोई हमलावर इसका शोषण कर सकता है?" बल्कि:

AppArmor/SELinux वास्तव में क्या देखता है?
ऑडिट लॉग क्या रिकॉर्ड करता है?
आपका SIEM/EDR क्या अवलोकन करता है?
नीति इंजन को क्या लगता है कि हुआ?

यदि कोई सुरक्षा-संवेदनशील संचालन होता है और प्रवर्तन स्तर उसका मूल्यांकन भी नहीं करता, तो आपके पास एक दृश्यता अंतर है — भले ही आज कोई हमलावर व्यावहारिक रूप से इसका दुरुपयोग कर सके या नहीं। यह अनुपालन, फोरेंसिक्स, और गहराई-में-रक्षा धारणाओं के लिए मायने रखता है।

B) व्यावहारिक एस्केलेशन पथ

वास्तविक दुनिया की शोषण-क्षमता का सवाल:

क्या यह एक विशेषाधिकार सीमा को पार करता है?
क्या हमलावर को इसे ट्रिगर करने के लिए मौजूदा रूट/CAP_BPF की आवश्यकता है?
क्या एक शोषण श्रृंखला आवश्यक है, या यह स्वतंत्र है?
वास्तविक प्रभाव क्या है — डेटा एक्सेस, विशेषाधिकार वृद्धि, नीति चोरी?

ये दो चीजें अलग हैं। एक खोज एक महत्वपूर्ण दृश्यता अंतर हो सकती है (आपकी निगरानी अंधी है) बिना एक व्यावहारिक विशेषाधिकार वृद्धि (हमलावर को पहले से रूट चाहिए) के। इसके विपरीत, एक खोज न्यूनतम पूर्वापेक्षाओं के साथ एक सीधा एस्केलेशन पथ हो सकता है।

पुनरुत्पादन मैट्रिक्स

प्रत्येक खोज के विशिष्ट कर्नेल/कॉन्फ़िग/विशेषाधिकार आवश्यकताएँ हैं। यदि आपका वातावरण मेल नहीं खाता, तो खोज पुनरुत्पादित नहीं होगी।

LID-001: eBPF पथनाम पुनर्लेखन

LID-002: io_uring MSG_RING

LID-004: BPF टोकन AppArmor अंधापन

LID-003: नया माउंट API

LID-005: AF_XDP tc ईग्रेस बायपास

त्वरित संदर्भ: प्रत्येक खोज को क्या ब्लॉक करता है

खोजें

पैटर्न

प्रत्येक खोज एक ही पैटर्न का अनुसरण करती है:``` ┌─────────────────────────────────────────────────────────────┐ │ THE LID PATTERN │ │ │ │ Kernel Subsystem A LSM Framework │ │ (eBPF / io_uring / mount API) (AppArmor / SELinux) │ │ │ │ ┌───────────────────┐ │ │ │ Performs operation │──── should call ──── security_*() │ │ │ or manipulates │ but │ │ │ security input │ DOESN'T ██ │ │ └───────────────────┘ │ │ │ │ The LSM framework is correct. │ │ The kernel just doesn't always use it. │ └─────────────────────────────────────────────────────────────┘

दो कर्नेल उपतंत्र। असंगत विश्वास धारणाएँ। एक अंतर।

<br>

---

## LID-001: eBPF Pathname Rewriting

**प्रमुख खोज।** `do_sys_openat2` पर एक BPF kprobe कर्नेल द्वारा कॉपी करने से पहले उपयोगकर्ता मेमोरी में फ़ाइलनाम को फिर से लिखता है। AppArmor पुनर्लिखित पथ की जाँच करता है, पहुँच प्रदान करता है। शून्य ऑडिट ट्रेस।```
  process: open("/tmp/secret.txt")
       │
       ▼
  do_sys_openat2()
       │
    ★ LID kprobe fires here
    │  bpf_probe_write_user()
    │  rewrites "/tmp/secret.txt" → "/tmp/.bypass_link"
       │
       ▼
  getname_flags()          ← kernel copies the (rewritten) path
       │
       ▼
  security_file_open()     ← LSM hooks check "/tmp/.bypass_link"
       │                      AppArmor: ALLOW ✓
       ▼
  VFS opens inode          ← same file content (hard link)
       │
       ▼
  return fd to process     ← success, zero audit trace

त्वरित आरंभ```bash

sudo ./scripts/check_prerequisites.sh sudo ./scripts/setup_env.sh make sudo ./scripts/setup_demo.sh sudo ./scripts/run_demo.sh

### डेमो आउटपुट```
╔══════════════════════════════════════════════════════════╗
║  Phase 1: AppArmor ENFORCING — access should be DENIED   ║
╚══════════════════════════════════════════════════════════╝

  $ /tmp/test_reader
  [-] DENIED: open() failed: Permission denied (errno=13)

╔══════════════════════════════════════════════════════════╗
║  Phase 2: Loading LID — BPF kprobe pathname rewrite       ║
╚══════════════════════════════════════════════════════════╝

  [*] BPF kprobe attached to do_sys_openat2

╔══════════════════════════════════════════════════════════╗
║  Phase 3: With LID active — access should be GRANTED      ║
╚══════════════════════════════════════════════════════════╝

  $ /tmp/test_reader
  [+] SUCCESS: Read 44 bytes: SECRET_DATA=this_is_protected_content_12345

╔══════════════════════════════════════════════════════════╗
║  Phase 4: Stealth check — audit log inspection             ║
╚══════════════════════════════════════════════════════════╝

  $ dmesg | grep apparmor | grep DENIED
  (empty — no denial was ever generated)

LID-002: io_uring MSG_RING लापता LSM हुक

IORING_OP_MSG_RING with IORING_MSG_SEND_FD io_uring रिंग्स के बीच फ़ाइल डिस्क्रिप्टर स्थानांतरित करता है बिना security_file_receive() को कॉल किए। हर अन्य fd स्थानांतरण तंत्र इसे कॉल करता है:``` MSG_RING SEND_FD: __io_fixed_fd_install() ← NO security_file_receive() FIXED_FD_INSTALL: receive_fd() ← security_file_receive() ✓ SCM_RIGHTS: receive_fd() ← security_file_receive() ✓ binder: security_binder_transfer_file() ✓

**बग स्थान:** `io_uring/msg_ring.c`, `io_msg_install_complete()` — सीधे `__io_fixed_fd_install()` को कॉल करता है, जिससे LSM हुक छूट जाता है।

**ftrace से सत्यापित:** `security_file_receive` SCM_RIGHTS के लिए फायर होता है लेकिन MSG_RING के लिए नहीं।

**प्रभावित:** Linux 5.18+ से v7.1-rc3 तक (2026-05-17 तक अनफिक्स्ड)।

**PoC:** [`findings/lid-002-iouring-msgring/msg_ring_bypass.c`](https://github.com/azqzazq1/lid/blob/HEAD/findings/lid-002-iouring-msgring/)

<br>

---

## LID-003: नया माउंट API AppArmor को बायपास करता है

नया माउंट API (`fsopen` + `fsconfig` + `fsmount` + `move_mount`) **कभी भी `security_sb_mount()` को कॉल नहीं करता** — यह एकमात्र माउंट हुक है जो AppArmor लागू करता है।```
  OLD API:  mount("proc", "/mnt", "proc", 0, NULL)
            → security_sb_mount()  → AppArmor: DENY ✗

  NEW API:  fsopen("proc") → fsconfig(CMD_CREATE) → fsmount() → move_mount()
            → security_sb_kern_mount()  → AppArmor: (not implemented) → ALLOW ✓

AppArmor 4 माउंट हुक पंजीकृत करता है। SELinux 14 पंजीकृत करता है। नया माउंट API उन हुकों का उपयोग करता है जिन्हें केवल SELinux लागू करता है।

अतिरिक्त अंतराल पाए गए:

open_tree(OPEN_TREE_CLONE): शून्य सुरक्षा हुक — बाइंड-माउंट नीति को बायपास करता है
mount_setattr(): कर्नेल में कोई LSM हुक मौजूद नहीं है
move_mount() के साथ डिटैच्ड माउंट: AppArmor NULL स्रोत पथ देखता है

विवरण: findings/lid-003-mount-api/

LID-004: BPF Token — AppArmor शून्य कवरेज

BPF टोकन सबसिस्टम (Linux 6.9+) यूज़र नेमस्पेस में अनप्रिविलेज्ड प्रक्रियाओं को BPF क्षमताएँ सौंपता है। कर्नेल 9 BPF LSM हुक परिभाषित करता है। SELinux वास्तविक avc_has_perm() प्रवर्तन के साथ सभी 9 को लागू करता है। AppArmor शून्य लागू करता है।``` Kernel defines 9 BPF LSM hooks: ┌─────────────────────────────────────────────────────────────────┐ │ bpf, bpf_map, bpf_prog, bpf_map_create, bpf_prog_load, │ │ bpf_token_create, bpf_token_free, bpf_token_cmd, │ │ bpf_token_capable │ └─────────────────────────────────────────────────────────────────┘

SELinux: ████████████████████████████ 9/9 implemented AppArmor: 0/9 implemented Smack: 0/9 implemented

On Ubuntu/Debian पर, bpffs delegation वाला एक कंटेनर:
- BPF टोकन बनाएं → AppArmor कुछ नहीं देखता
- टोकन का उपयोग करके ट्रेसिंग प्रोग्राम लोड करें → AppArmor कुछ नहीं देखता
- CAP_PERFMON सौंपें → Spectre mitigations अक्षम करें → AppArmor कुछ नहीं देखता

**विवरण:** [`findings/lid-004-bpf-token/`](https://github.com/azqzazq1/lid/blob/HEAD/findings/lid-004-bpf-token/)

<br>

---

## LID-005: AF_XDP tc Egress Bypass डिफ़ॉल्ट Docker कंटेनर से

AF_XDP का कॉपी-मोड ट्रांसमिट पथ (`xsk_generic_xmit` → `__dev_direct_xmit`) **tc egress classifiers को बाईपास करता है** कंटेनर के इंटरफ़ेस पर। tc u32 DROP-ALL के साथ सत्यापित — AF_PACKET अवरुद्ध, AF_XDP पास होता है।

**हालांकि:** Cilium v1.19 (kind cluster, deny-all egress NetworkPolicy) के साथ परीक्षण किया गया — **Cilium को बाईपास नहीं किया गया।** Cilium नोड-साइड veth पीयर इनग्रेस (`cil_from_container` tcx/ingress के माध्यम से) पर लागू करता है + स्रोत IP सत्यापन है। AF_XDP पैकेट `bpf_lxc.c:1603` पर "Invalid source ip" के रूप में गिरा दिए गए। प्रभाव नेटवर्क पॉलिसी के लिए पूरी तरह से tc egress classifiers पर निर्भर वातावरणों तक सीमित है (plain Docker + tc rules, no CNI)।```
  Normal TX path:
  socket → dev_queue_xmit() → sch_handle_egress() → tc classifiers → driver
                                     ↑
                                  ENFORCED (Cilium eBPF, Calico, tc u32)

  AF_XDP copy-mode TX:
  xsk_sendmsg() → xsk_generic_xmit() → __dev_direct_xmit() → driver
                                              ↑
                                           SKIPPED (tc never runs)

कर्नेल 6.8.0 पर Docker डिफ़ॉल्ट कंटेनरों के साथ गतिशील रूप से सत्यापित:``` tc egress DROP-ALL on container eth0:

AF_PACKET sendto → ENOBUFS (BLOCKED by tc) AF_XDP sendto → 0 (BYPASS — 3 spoofed packets reached docker0 bridge)

पैकेट्स हमलावर-नियंत्रित ईथरनेट हेडर — स्पूफ़्ड MAC, स्पूफ़्ड IP — ले जाते हैं और सक्रिय DROP नीति के बावजूद Docker ब्रिज तक पहुँचते हैं।

**PoC + विवरण:** [`findings/lid-005-afxdp-tc-bypass/`](https://github.com/azqzazq1/lid/blob/HEAD/findings/lid-005-afxdp-tc-bypass/)

<br>

---

## आर्किटेक्चर: BPF LSM इसे क्यों ठीक नहीं कर सकता```
  LSM Hook Chain: call_int_hook(file_open, ...)

  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
  │  Lockdown    │──>│  Capability  │──>│   AppArmor   │──>│  BPF LSM    │
  │  return 0    │   │  return 0    │   │  return -13  │   │  (never     │
  │  (allow)     │   │  (allow)     │   │  (DENY) ██   │   │   reached)  │
  └─────────────┘   └─────────────┘   └──────┬───────┘   └─────────────┘
                                              │
                                         loop breaks
                                         RC = -EACCES

  ★ The LSM framework is correct. No module can undo another's denial.
  ★ LID operates OUTSIDE the framework — before hooks run, or where hooks don't exist.

साथी: SunnyDayBPF```

               ┌───────────────────────────────────────┐
               │          THE ATTACK TIMELINE           │
               │                                       │

Syscall Entry │ ★ LID ─── manipulates input │ │ │ (security check sees wrong data) │ ▼ │ │ LSM Check │ LSM allows (or never runs) ✓ │ │ │ │ ▼ │ │ Syscall Exit │ ★ SunnyDayBPF ─── rewrites telemetry │ │ │ (monitoring sees wrong data) │ ▼ │ │ Audit/Log │ SIEM sees nothing ✓ │ │ │ │ Combined: ghost access │ └───────────────────────────────────────┘

<br>

## परियोजना संरचना```
LID/
├── src/
│   ├── bpf/
│   │   └── lid.bpf.c              # BPF kprobe — pathname rewriter (LID-001)
│   └── loader/
│       └── lid_loader.c           # Userspace loader + event monitor
├── findings/
│   ├── lid-001-ebpf-pathname/     # eBPF pathname rewriting bypass
│   ├── lid-002-iouring-msgring/   # io_uring MSG_RING missing LSM hook
│   │   ├── msg_ring_bypass.c      # PoC with ftrace verification
│   │   └── ADVISORY.md            # Technical advisory
│   ├── lid-003-mount-api/         # New mount API AppArmor bypass
│   ├── lid-004-bpf-token/        # BPF token AppArmor/Smack zero coverage
│   └── lid-005-afxdp-tc-bypass/  # AF_XDP tc egress bypass from container
├── tests/
│   └── test_reader.c              # Victim binary for LID-001 demo
├── scripts/
│   ├── check_prerequisites.sh     # Verify system requirements
│   ├── setup_env.sh               # Install build dependencies
│   ├── setup_demo.sh              # Create demo environment
│   ├── run_demo.sh                # Run full LID-001 demonstration
│   └── teardown.sh                # Clean up everything
├── docs/
│   └── RESEARCH.md                # Full technical research paper
├── publish/                       # Articles for Medium, dev.to, etc.
├── Makefile
├── LICENSE
├── SECURITY.md
└── README.md

गुप्त प्रोफ़ाइल (LID-001)

शमन उपाय

विस्तृत शमन मार्गदर्शन के लिए, docs/RESEARCH.md देखें।

आवश्यकताएँ

पूर्ण प्रति-खोज विवरण के लिए Reproducibility Matrix देखें। सारांश:

लेखक

Azizcan Daştan
Milenium Security

GitHub: @azqzazq1

अस्वीकरण

यह उपकरण केवल अधिकृत सुरक्षा परीक्षण, अनुसंधान और शैक्षिक उद्देश्यों के लिए प्रकाशित किया गया है। उन सिस्टमों के विरुद्ध उपयोग न करें जिनके आप मालिक नहीं हैं या जिनके परीक्षण की स्पष्ट लिखित अनुमति नहीं है।

LID — क्योंकि अखंडता कभी लॉक नहीं थी।

LID-001	महत्वपूर्ण — AppArmor कुछ नहीं देखता, ऑडिट लॉग खाली, शून्य फोरेंसिक निशान	सीमित — रूट या CAP_BPF+CAP_PERFMON आवश्यक (पहले से ही विशेषाधिकार प्राप्त)। यह विशेषाधिकार वृद्धि नहीं है। प्रभाव: नीति चोरी + ऑडिट अंधापन।
LID-002	उच्च — `security_file_receive()` कभी फायर नहीं होता, fd स्थानांतरण सभी LSM के लिए अदृश्य	उच्च — अविशेषाधिकार प्राप्त उपयोगकर्तास्थान से io_uring के माध्यम से काम करता है। बिना किसी विशेषाधिकार के LSM प्रवर्तन सीमा पार करता है।
LID-003	उच्च — `security_sb_mount()` बायपास हुआ, AppArmor माउंट नीति मृत कोड है	मध्यम — माउंट नेमस्पेस एक्सेस की आवश्यकता है (उपयोगकर्ता ns में CAP_SYS_ADMIN)। कई कंटेनर कॉन्फ़िग में उपलब्ध।
LID-004	महत्वपूर्ण — AppArmor कुछ नहीं देखता, शून्य BPF हुक (0/9), किसी भी BPF टोकन संचालन के लिए कोई ऑडिट ट्रेस नहीं	मध्यम — होस्ट द्वारा bpffs प्रतिनिधिमंडल + उपयोगकर्ता नेमस्पेस में CAP_BPF आवश्यक। BPF प्रतिनिधिमंडल (LXD/Incus) वाले कंटेनर रनटाइम में उपलब्ध।
LID-005	मध्यम — कंटेनर इंटरफ़ेस पर tc ईग्रेस क्लासिफायर कभी AF_XDP ट्रैफ़िक का मूल्यांकन नहीं करते	सीमित — कंटेनर eth0 पर tc ईग्रेस को बायपास करता है (सत्यापित)। Cilium बायपास नहीं हुआ — नोड-साइड veth इनग्रेस पर प्रवर्तन + स्रोत IP सत्यापन (परीक्षण किया गया)। प्रभाव केवल tc-मात्र ईग्रेस फ़िल्टरिंग वाले सादे-Docker सेटअप तक सीमित।

कर्नेल संस्करण	5.x+	5.15, 6.1, 6.6, 6.8 पर परीक्षित
`CONFIG_BPF_SYSCALL`	`=y`	सभी प्रमुख डिस्ट्रो पर डिफ़ॉल्ट
`CONFIG_BPF_KPROBE_OVERRIDE`	`=y`	Ubuntu/Debian इसे सक्षम करते हैं, RHEL नहीं
`CONFIG_SECURITY_APPARMOR`	`=y`	लक्ष्य LSM AppArmor होना चाहिए
AppArmor प्रोफ़ाइल	प्रवर्तन, लक्ष्य पथ पर नियम अस्वीकार करें	किसी भी पथ-आधारित अस्वीकार नियम के साथ काम करता है
विशेषाधिकार	`root` या `CAP_BPF` + `CAP_PERFMON`	अविशेषाधिकार प्राप्त रूप से नहीं चल सकता
`kernel.lockdown`	`none` या `integrity`	`confidentiality` मोड kprobe अटैचमेंट को ब्लॉक करता है
`kernel.unprivileged_bpf_disabled`	अप्रासंगिक	CAP_BPF की आवश्यकता वैसे भी
`fs.protected_hardlinks`	क्रॉस-यूज़र लिंक के लिए `0`	`1` (डिफ़ॉल्ट) अभी भी समान-उपयोगकर्ता हार्ड लिंक की अनुमति देता है
SELinux बजाय AppArmor	काम नहीं करता	SELinux इनोड-आधारित है, पथनाम-आधारित नहीं

कर्नेल संस्करण	6.0+	`IORING_MSG_SEND_FD` 6.0 में जोड़ा गया
`CONFIG_IO_URING`	`=y`	सभी प्रमुख डिस्ट्रो पर डिफ़ॉल्ट
विशेषाधिकार	कोई नहीं	अविशेषाधिकार प्राप्त उपयोगकर्तास्थान से काम करता है
`io_uring_disabled` sysctl	`0` (डिफ़ॉल्ट)	`2` अविशेषाधिकार प्राप्त को ब्लॉक करता है, `1` सभी को ब्लॉक करता है
लक्ष्य LSM	कोई भी (SELinux, AppArmor, Smack)	`security_file_receive()` एक सामान्य LSM हुक है
`kernel.lockdown`	अप्रासंगिक	कोई BPF शामिल नहीं

कर्नेल संस्करण	6.9+	BPF टोकन 6.9 में पेश किया गया
`CONFIG_BPF_SYSCALL`	`=y`	सभी प्रमुख डिस्ट्रो पर डिफ़ॉल्ट
`CONFIG_SECURITY_APPARMOR`	`=y`	Ubuntu/Debian डिफ़ॉल्ट
bpffs प्रतिनिधिमंडल के साथ	हाँ	होस्ट को `delegate_*` विकल्पों के साथ माउंट करना होगा
विशेषाधिकार	उपयोगकर्ता नेमस्पेस में CAP_BPF	userns रूट के लिए तुच्छ रूप से उपलब्ध
SELinux बजाय AppArmor	प्रभावित नहीं	SELinux सभी 9 BPF हुक लागू करता है

कर्नेल संस्करण	5.2+	`fsopen`/`fsmount` 5.2 में पेश किया गया
`CONFIG_SECURITY_APPARMOR`	`=y`	केवल AppArmor प्रभावित है
विशेषाधिकार	उपयोगकर्ता नेमस्पेस में `CAP_SYS_ADMIN`	`unshare -m` के साथ उपलब्ध
SELinux बजाय AppArmor	काम नहीं करता	SELinux `security_sb_kern_mount()` लागू करता है
कंटेनर रनटाइम	seccomp फ़िल्टर पर निर्भर करता है	Docker डिफ़ॉल्ट seccomp `fsopen` को ब्लॉक करता है — Podman/LXC शायद न करें

कर्नेल संस्करण	4.18+	AF_XDP 4.18 में पेश किया गया
`CONFIG_XDP_SOCKETS`	`=y`	सभी प्रमुख डिस्ट्रो पर डिफ़ॉल्ट
विशेषाधिकार	केवल CAP_NET_RAW	Docker, Kubernetes पॉड में डिफ़ॉल्ट
कंटेनर रनटाइम	Docker, K8s, LXC	डिफ़ॉल्ट क्षमता सेट
tc-आधारित नेटवर्क नीति	हाँ	Cilium eBPF, Calico, tc u32/flower

Ubuntu 22.04+ (AppArmor, डिफ़ॉल्ट)	काम करता है	काम करता है	काम करता है	काम करता है (6.9+)	काम करता है
Debian 12+ (AppArmor)	काम करता है	काम करता है	काम करता है	काम करता है (6.9+)	काम करता है
RHEL/Fedora (SELinux)	नहीं	काम करता है	नहीं	नहीं	काम करता है
`lockdown=confidentiality`	नहीं	काम करता है	काम करता है	आंशिक रूप से	काम करता है
अविशेषाधिकार प्राप्त उपयोगकर्ता	नहीं	काम करता है	उपयोगकर्ता ns पर निर्भर करता है	bpffs प्रतिनिधिमंडल पर निर्भर करता है	नहीं
कंटेनर (बिना CAP_BPF)	नहीं	io_uring पर निर्भर करता है	seccomp पर निर्भर करता है	नहीं	काम करता है
कंटेनर (CAP_NET_RAW हटा दिया गया)	नहीं	निर्भर करता है	निर्भर करता है	नहीं	नहीं

LID-001	eBPF kprobe पथनाम पुनर्लेखन	AppArmor	kprobe `copy_from_user` से पहले फ़ाइलनाम को पुनर्लेखित करता है → AppArmor गलत पथ की जाँच करता है
LID-002	io_uring MSG_RING SEND_FD	SELinux, AppArmor, Smack	fd स्थानांतरण `security_file_receive()` को छोड़ देता है — हर दूसरा fd स्थानांतरण इसे कॉल करता है
LID-003	नया माउंट API (fsopen/fsmount)	AppArmor	`security_sb_mount()` कभी कॉल नहीं होता — AppArmor का एकमात्र माउंट हुक बायपास हुआ
LID-004	BPF टोकन प्रतिनिधिमंडल	AppArmor, Smack	शून्य BPF हुक — टोकन निर्माण, उपयोग, क्षमता प्रतिनिधिमंडल पूरी तरह से अदृश्य
LID-005	AF_XDP `__dev_direct_xmit`	tc ईग्रेस, Cilium, Calico	डिफ़ॉल्ट Docker से कॉपी-मोड TX tc क्लासिफायर को बायपास करता है — जाली पैकेट ब्रिज तक पहुँचते हैं

AppArmor ऑडिट लॉग	कुछ नहीं	अस्वीकार कभी नहीं होता
`auditd` / `journald`	कुछ नहीं	कोई सुरक्षा घटना उत्पन्न नहीं हुई
`dmesg`	एक बार की चेतावनी	सामान्य `bpf_probe_write_user` संदेश
`bpftool prog list`	दृश्यमान	संलग्न kprobe दिखाता है (यदि जाँच की जाए)
डिस्क पर हार्ड लिंक	पता लगाने योग्य	`find -samefile` (धीमा, शोरगुल वाला)

`kernel.lockdown=confidentiality`	BPF को पूरी तरह से अवरुद्ध करता है	वैध निगरानी को समाप्त करता है
`bpf_probe_write_user` अक्षम करें	LID-001 पथ पुनर्लेखन को रोकता है	कर्नेल पुनर्निर्माण की आवश्यकता है
`fs.protected_hardlinks=1`	हार्ड लिंक निर्माण को सीमित करता है	आधुनिक कर्नेल पर डिफ़ॉल्ट
`bpftool prog list` की निगरानी करें	संलग्न प्रोब का पता लगाता है	सक्रिय पोलिंग की आवश्यकता है
SELinux पर स्थानांतरित करें	इनोड-आधारित, पथ पुनर्लेखन को पराजित करता है	जटिल स्थानांतरण
io_uring को प्रतिबंधित करें	LID-002 को अवरुद्ध करता है	एप्लिकेशन तोड़ सकता है

LID-001	5.x+	root / CAP_BPF+CAP_PERFMON	केवल AppArmor
LID-002	6.0+	कोई नहीं	कोई भी (SELinux, AppArmor, Smack)
LID-003	5.2+	CAP_SYS_ADMIN (user ns ok)	केवल AppArmor
LID-004	6.9+	CAP_BPF (user ns ok)	AppArmor, Smack
LID-005	4.18+	CAP_NET_RAW (Docker डिफ़ॉल्ट)	tc egress (Cilium, Calico, आदि)

LID

सबसे लोकप्रिय