Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
LID — LID — Linux Integrity Drift: обход AppArmor через переписывание путей в eBPF. Манипулирование аргументами системных вызовов до LSM с нулевым следом в аудите. «Linux is Dying» | Kitploit
Инструменты/GitHubGitHub/azqzazq1/lid
Повышение привилегийАнализ уязвимостейЭксплуатацияОбход IDS/IPSТестирование на ПроникновениеАнализ Бинарных ФайловСтатьи и ИсследованияОбучение и ОбразованиеRed Teaming
GitHubazqzazq1/lid

LID

LID — Linux Integrity Drift: обход AppArmor через переписывание путей в eBPF. Манипулирование аргументами системных вызовов до LSM с нулевым следом в аудите. «Linux is Dying»

2012 месяцев назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться
Репозиторий


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

Linux Integrity Drift

— «Linux умирает» —


Систематическое обнаружение путей в коде ядра, обходящих гарантии безопасности LSM
Ворота никогда не взламывали. Их просто обошли.



Что такое LID?

У фреймворка Linux Security Module есть одна ключевая гарантия, которая держится уже 20+ лет:

Модули безопасности могут только добавлять ограничения. Они никогда не могут их снимать.

Эта гарантия верна. LID её не нарушает.

LID находит пути в коде ядра, которые полностью обходят хуки LSM — подсистемы, выполняющие чувствительные с точки зрения безопасности операции, не обращаясь к фреймворку LSM. Проверка безопасности корректна. Проблема в том, что ядро её просто не запрашивает.


Понимание того, чем является LID (а чем — нет)

Каждая находка имеет два различных аспекта, которые не следует смешивать:

A) Пробел видимости политики

Архитектурное слепое пятно. Вопрос не в том, «может ли атакующий это эксплуатировать?», а в следующем:

  • Что AppArmor/SELinux на самом деле видит?
  • Что записывает журнал аудита?
  • Что наблюдает ваш SIEM/EDR?
  • Что думает движок политик, что произошло?

Если чувствительная с точки зрения безопасности операция выполняется, а уровень принудительного контроля её даже не оценивает, у вас пробел видимости — независимо от того, может ли атакующий практически злоупотребить этим сегодня. Это имеет значение для комплаенса, криминалистики и предположений об эшелонированной обороне.

B) Практический путь эскалации

Вопрос реальной эксплуатируемости:

  • Пересекает ли это границу привилегий?
  • Нужны ли атакующему существующие root/CAP_BPF для запуска?
  • Требуется ли цепочка эксплойтов или этого достаточно самого по себе?
  • Каково фактическое воздействие — доступ к данным, повышение привилегий, обход политики?

Это две разные вещи. Находка может быть критическим пробелом видимости (ваш мониторинг слеп), не будучи практическим повышением привилегий (атакующему уже нужен root). И наоборот, находка может быть прямым путём эскалации с минимальными предпосылками.


Матрица воспроизводимости

У каждой находки есть конкретные требования к ядру/конфигурации/привилегиям. Если ваше окружение не совпадает, находка не воспроизведётся.

LID-001: Переписывание пути в eBPF

LID-002: io_uring MSG_RING

LID-004: Слепота AppArmor к BPF-токенам

LID-003: Новый API монтирования

LID-005: Обход tc egress через AF_XDP

Краткая справка: что блокирует каждую находку


Находки


Закономерность

Каждая находка следует одной и той же закономерности:``` ┌─────────────────────────────────────────────────────────────┐ │ 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. │ └─────────────────────────────────────────────────────────────┘

root@kitploit:~
Two kernel subsystems. Incompatible trust assumptions. One gap.

<br>

---

## LID-001: eBPF Pathname Rewriting

**The flagship finding.** A BPF kprobe on `do_sys_openat2` rewrites the filename in user memory before the kernel copies it. AppArmor checks the rewritten path, grants access. Zero audit trace.```
  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

root@kitploit:~
### Демо-вывод```
╔══════════════════════════════════════════════════════════╗
║  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 с 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() ✓

root@kitploit:~
**Bug location:** `io_uring/msg_ring.c`, `io_msg_install_complete()` — напрямую вызывает `__io_fixed_fd_install()`, пропуская хук LSM.

**Verified with ftrace:** `security_file_receive` срабатывает для SCM_RIGHTS, но не для MSG_RING.

**Affected:** 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 mount-хука. SELinux регистрирует 14. Новый mount API использует хуки, которые реализует только SELinux.

Обнаружены дополнительные пробелы:

  • open_tree(OPEN_TREE_CLONE): Ноль security-хуков — обход политики bind-mount
  • mount_setattr(): В ядре вообще не существует LSM-хука
  • move_mount() с отсоединёнными монтированиями: AppArmor видит исходный путь как NULL

Подробности: findings/lid-003-mount-api/



LID-004: BPF Token — нулевое покрытие AppArmor

Подсистема BPF token (Linux 6.9+) делегирует BPF-возможности непривилегированным процессам в пользовательских пространствах имён. Ядро определяет 9 BPF LSM-хуков. SELinux реализует все 9 с реальным контролем через avc_has_perm(). 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

root@kitploit:~
В 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 Egress в AF_XDP из стандартного Docker-контейнера

Путь передачи AF_XDP в режиме копирования (`xsk_generic_xmit` → `__dev_direct_xmit`) **обходит классификаторы tc egress** на интерфейсе контейнера. Проверено с помощью tc u32 DROP-ALL — AF_PACKET блокируется, AF_XDP проходит.

**Однако:** Протестировано с Cilium v1.19 (kind-кластер, deny-all egress NetworkPolicy) — **Cilium обойти не удалось.** Cilium применяет контроль на ingress veth-пира на стороне узла (`cil_from_container` через tcx/ingress) + проверку исходного IP-адреса. Пакеты AF_XDP отбрасывались как "Invalid source ip" в `bpf_lxc.c:1603`. Влияние ограничено средами, которые полагаются исключительно на классификаторы tc egress для сетевых политик (обычный 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)

Динамически проверено на ядре 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)

root@kitploit:~
Пакеты несут управляемые атакующим Ethernet-заголовки — поддельный 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.

Компаньон: SunnyDayBPF```

root@kitploit:~
               ┌───────────────────────────────────────┐
               │          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 │ └───────────────────────────────────────┘

root@kitploit:~
<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.


Требования

Полные подробности по каждой находке см. в Матрице воспроизводимости. Сводка:


Автор

Azizcan Daştan
Milenium Security

  • GitHub: @azqzazq1

Отказ от ответственности

Этот инструмент опубликован только для авторизованного тестирования безопасности, исследований и образовательных целей. Не используйте его против систем, которыми вы не владеете или на тестирование которых у вас нет явного письменного разрешения.


LID — потому что целостность никогда не была заблокирована.

Скачать инструмент
НаходкаПробел видимостиПрактическая эскалация
LID-001Критический — AppArmor ничего не видит, журнал аудита пуст, ноль криминалистических следовОграниченная — требует root или CAP_BPF+CAP_PERFMON (уже привилегирован). Не повышение привилегий. Воздействие: обход политики + слепота аудита.
LID-002Высокий — security_file_receive() никогда не срабатывает, передача fd невидима для всех LSMВысокая — работает из непривилегированного пользовательского пространства через io_uring. Пересекает границу принудительного контроля LSM без каких-либо привилегий.
LID-003Высокий — security_sb_mount() обойдён, политика монтирования AppArmor — мёртвый кодСредняя — требует доступ к namespace монтирования (CAP_SYS_ADMIN в user ns). Доступен во многих конфигурациях контейнеров.
LID-004Критический — AppArmor ничего не видит, ноль BPF-хуков (0/9), нет следов аудита для любой операции с BPF-токеномСредняя — требует делегирования bpffs хостом + CAP_BPF в user namespace. Доступен в контейнерных рантаймах с делегированием BPF (LXD/Incus).
LID-005Средний — классификаторы tc egress на интерфейсе контейнера никогда не оценивают трафик AF_XDPОграниченная — обходит tc egress на eth0 контейнера (подтверждено). Cilium НЕ обойдён — применяет контроль на входящем veth со стороны узла + проверку исходного IP (протестировано). Воздействие ограничено конфигурациями plain-Docker с фильтрацией только через tc egress.
УсловиеТребуетсяПримечания
Версия ядра5.x+Протестировано на 5.15, 6.1, 6.6, 6.8
CONFIG_BPF_SYSCALL=yПо умолчанию во всех крупных дистрибутивах
CONFIG_BPF_KPROBE_OVERRIDE=yUbuntu/Debian включают, RHEL нет
CONFIG_SECURITY_APPARMOR=yЦелевой LSM должен быть AppArmor
Профиль AppArmorEnforcing, правило deny на целевой путьРаботает с любым правилом deny на основе пути
Привилегииroot или CAP_BPF + CAP_PERFMONНе может работать без привилегий
kernel.lockdownnone или integrityРежим confidentiality блокирует присоединение kprobe
kernel.unprivileged_bpf_disabledНе важноВ любом случае требуется CAP_BPF
fs.protected_hardlinks0 для межпользовательских ссылок1 (по умолчанию) всё ещё разрешает жёсткие ссылки того же пользователя
SELinux вместо AppArmorНе работаетSELinux основан на inode, а не на пути
УсловиеТребуетсяПримечания
Версия ядра6.0+IORING_MSG_SEND_FD добавлен в 6.0
CONFIG_IO_URING=yПо умолчанию во всех крупных дистрибутивах
ПривилегииНетРаботает из непривилегированного пользовательского пространства
sysctl io_uring_disabled0 (по умолчанию)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 в user namespaceТривиально доступен для root в userns
SELinux вместо AppArmorНе затронутSELinux реализует все 9 BPF-хуков
УсловиеТребуетсяПримечания
Версия ядра5.2+fsopen/fsmount появились в 5.2
CONFIG_SECURITY_APPARMOR=yЗатронут только AppArmor
ПривилегииCAP_SYS_ADMIN в user namespaceДоступно с unshare -m
SELinux вместо AppArmorНе работаетSELinux реализует security_sb_kern_mount()
Контейнерный рантаймЗависит от seccomp-фильтраСтандартный seccomp Docker блокирует fsopen — Podman/LXC могут не блокировать
УсловиеТребуетсяПримечания
Версия ядра4.18+AF_XDP появился в 4.18
CONFIG_XDP_SOCKETS=yПо умолчанию во всех крупных дистрибутивах
ПривилегииТолько CAP_NET_RAWПо умолчанию в Docker и подах Kubernetes
Контейнерный рантаймDocker, K8s, LXCСтандартный набор capabilities
Сетевая политика на основе tcДаCilium eBPF, Calico, tc u32/flower
ОкружениеLID-001LID-002LID-003LID-004LID-005
Ubuntu 22.04+ (AppArmor, по умолчанию)РаботаетРаботаетРаботаетРаботает (6.9+)Работает
Debian 12+ (AppArmor)РаботаетРаботаетРаботаетРаботает (6.9+)Работает
RHEL/Fedora (SELinux)НетРаботаетНетНетРаботает
lockdown=confidentialityНетРаботаетРаботаетЧастичноРаботает
Непривилегированный пользовательНетРаботаетЗависит от user nsЗависит от делегирования bpffsНет
Контейнер (без CAP_BPF)НетЗависит от io_uringЗависит от seccompНетРаботает
Контейнер (снят CAP_NET_RAW)НетЗависитЗависитНетНет
IDВекторЦельЧто происходит
LID-001Переписывание пути через eBPF kprobeAppArmorkprobe переписывает имя файла до copy_from_user → AppArmor проверяет не тот путь
LID-002io_uring MSG_RING SEND_FDSELinux, AppArmor, SmackПередача fd пропускает security_file_receive() — любой другой способ передачи fd вызывает его
LID-003Новый API монтирования (fsopen/fsmount)AppArmorsecurity_sb_mount() никогда не вызывается — единственный хук монтирования AppArmor обойдён
LID-004Делегирование BPF-токеновAppArmor, SmackНоль BPF-хуков — создание токена, его использование и делегирование capabilities полностью невидимы
LID-005AF_XDP __dev_direct_xmittc egress, Cilium, CalicoTX в copy-режиме из стандартного Docker обходит 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Основан на inode, нейтрализует перезапись путиСложная миграция
Ограничение io_uringБлокирует LID-002Может нарушить работу приложений
НаходкаМин. версия ядраПривилегииЦель
LID-0015.x+root / CAP_BPF+CAP_PERFMONтолько AppArmor
LID-0026.0+НетЛюбая (SELinux, AppArmor, Smack)
LID-0035.2+CAP_SYS_ADMIN (user ns достаточно)только AppArmor
LID-0046.9+CAP_BPF (user ns достаточно)AppArmor, Smack
LID-0054.18+CAP_NET_RAW (по умолчанию в Docker)tc egress (Cilium, Calico и т. д.)