LID

Two kernel subsystems. Incompatible trust assumptions. One gap.

<br>

---

## LID-001: eBPF إعادة كتابة اسم المسار

**الاكتشاف الرئيسي.** يعيد كشف BPF kprobe على `do_sys_openat2` كتابة اسم الملف في ذاكرة المستخدم قبل أن تنسخه النواة. يقوم 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

### إخراج توضيحي```
╔══════════════════════════════════════════════════════════╗
║  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)

// security_file_receive() call from __receive_fd()
// security_file_receive() call from scm_recv()
// But io_uring does not call it

**موقع الخلل:** `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: واجهة التركيب الجديدة تتجاوز AppArmor

واجهة التركيب الجديدة (`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 ✓

على Ubuntu/Debian، يمكن لحاوية مع تفويض bpffs أن:
- تنشئ رموز BPF → لا يرى AppArmor شيئًا
- تستخدم الرموز لتحميل برامج التتبع → لا يرى AppArmor شيئًا
- تفوض CAP_PERFMON → تعطيل تخفيفات Spectre → لا يرى AppArmor شيئًا

**التفاصيل:** [`findings/lid-004-bpf-token/`](https://github.com/azqzazq1/lid/blob/HEAD/findings/lid-004-bpf-token/)

<br>

---

## LID-005: تجاوز خروج tc لـ AF_XDP من حاوية Docker الافتراضية

مسار الإرسال لوضع النسخ في AF_XDP (`xsk_generic_xmit` → `__dev_direct_xmit`) **يتجاوز مصنفات tc للخروج** على واجهة الحاوية. تم التحقق باستخدام tc u32 DROP-ALL — تم حظر AF_PACKET، ومرت AF_XDP.

**مع ذلك:** تم اختبارها مع Cilium v1.19 (مجموعة kind، سياسة شبكة خروج deny-all) — **لم يتم تجاوز Cilium.** يقوم Cilium بالفرض على دخول نظير veth جانب العقدة (`cil_from_container` عبر tcx/ingress) + لديه التحقق من عنوان IP المصدر. تم إسقاط حزم AF_XDP كـ "Invalid source ip" في `bpf_lxc.c:1603`. التأثير محدود على البيئات التي تعتمد فقط على مصنفات tc للخروج لسياسة الشبكة (Docker عادي + قواعد tc، بدون 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)

تحمل الحزم رؤوس إيثرنت يتحكم بها المهاجم — MAC مزيفة، IP مزيفة — وتصل إلى جسر Docker على الرغم من سياسة DROP النشطة.

**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.

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

<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