eBPF для слежки и прямые системные вызовы

В предшествующих разделах курса детально исследовалось взаимодействие прикладных процессов с операционной системой через стандартные интерфейсы: от манипуляций с переменными окружения и разделяемыми библиотеками до повышения привилегий через конфигурационные файлы и механизмы ядра. На уровне пользователя большинство программ опирается на стандартную библиотеку языка C (libc), которая служит связующим звеном между прикладным кодом и ядром Linux ¹. Однако при решении задач глубокого аудита, скрытного мониторинга и противодействия системам обнаружения атак (EDR) модель взаимодействия радикально меняется.

Современные средства защиты традиционно размещают перехватчики в пространстве пользователя, отслеживая библиотечные вызовы. В ответ на это возникли техники прямых системных вызовов (англ. direct syscalls), позволяющие приложению обращаться к ядру напрямую через инструкцию процессора syscall, минуя любые пользовательские библиотеки и установленные в них ловушки ². С другой стороны, само ядро Linux эволюционировало благодаря технологии eBPF (англ. Extended Berkeley Packet Filter): теперь ядро представляет собой полностью программируемую среду, способную перехватывать и анализировать любые действия процессов на уровне ring0 без модификации исходного кода ядра и без риска вызвать сбой системы ³.

В данной теме изучаются архитектура виртуальной машины eBPF в ядре Linux, принципы скрытого перехвата клавиатурного ввода через хукинг системного вызова sys_read, правила конвенции вызовов x86_64 и реализация прямых системных вызовов для обхода user-mode перехватчиков. В завершение рассматриваются методы обнаружения eBPF-программ средствами системного администратора и форензик-аналитика ³.

Архитектурная схема перехвата системных вызовов через eBPF представлена на рисунке 1.

Архитектура eBPF и механизмы динамической трассировки

Программируемое ядро: виртуальная машина, верификатор и JIT

Исторически для наблюдения за поведением ядра требовалось либо разрабатывать модули ядра (.ko), либо применять тяжеловесную статическую трассировку. Модули ядра работают в привилегированном режиме ring0, и любая ошибка в указателях или разыменование нулевого адреса приводит к аварийной остановке операционной системы (kernel panic) ¹. Технология eBPF коренным образом изменила данный подход, предоставив изолированную виртуальную машину непосредственно внутри ядра.

Программа eBPF представляет собой последовательность 64-битных инструкций виртуального процессора, оперирующего 11 регистрами (от r0 до r10, где r10 — неизменяемый указатель стека). Жизненный цикл программы eBPF состоит из следующих этапов ²:

1. Компиляция: исходный код на языке C транслируется компилятором clang с флагом -target bpf в двоичный байткод.
2. Загрузка: непривилегированный или привилегированный процесс передаёт байткод в ядро с помощью системного вызова bpf(BPF_PROG_LOAD, ...).
3. Верификация: статический верификатор ядра выполняет глубокий анализ графа потока управления (CFG). Проверяется отсутствие бесконечных циклов, недостижимого кода, выход за границы стека и попытки несанкционированного доступа к памяти ядра. Если верификатор находит потенциальную угрозу стабильности, загрузка программы отклоняется.
4. JIT-компиляция: одобренный байткод компилируется «на лету» (Just-In-Time) в машинные инструкции целевого процессора (например, x86_64) и прикрепляется к выбранному событию ядра.

Точки перехвата: kprobes, tracepoints и uprobes

Исполнение загруженной программы eBPF активируется при наступлении определённых системных событий. Выбор точки перехвата определяет полноту получаемой информации и устойчивость трейсера к обновлениям ядра ²:

Разница между kprobe и fentry не косметическая. kprobe подменяет первые байты функции ядра точкой останова (int3 или jmp), затем во временном обработчике восстанавливает оригинальные инструкции и эмулирует их выполнение — это дорого и оставляет след в виде модифицированного кода ядра. fentry использует механизм ftrace и трамплины, которые компилятор расставляет при сборке ядра (-pg/-mfentry): код функции не меняется, вызов программы eBPF добавляется косвенно через таблицу трамплинов ⁶. Для обнаружения это принципиально: kprobe виден по модифицированным байтам функции, а fentry — только по записи в таблице трамплинов и по наличию самой программы.

Точки трассировки tracepoints являются предпочтительными для мониторинга системных вызовов, поскольку их сигнатуры зафиксированы в исходном коде ядра Linux и не меняются между минорными версиями дистрибутива ³. Просмотреть доступные статические точки перехвата системных вызовов можно через виртуальную файловую систему tracefs:

ls /sys/kernel/tracing/events/syscalls | grep -E 'sys_enter_(read|write|execve)'

sys_enter_execve
sys_enter_execveat
sys_enter_read
sys_enter_readv
sys_enter_write
sys_enter_writev

Каждая точка трассировки имеет файл описания формата format, где перечислены типы и смещения аргументов системного вызова:

cat /sys/kernel/tracing/events/syscalls/sys_enter_read/format

name: sys_enter_read
ID: 712
format:
	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
	field:int common_pid;	offset:4;	size:4;	signed:1;

	field:int __syscall_nr;	offset:8;	size:4;	signed:1;
	field:unsigned int fd;	offset:16;	size:8;	signed:0;
	field:char * buf;	offset:24;	size:8;	signed:0;
	field:size_t count;	offset:32;	size:8;	signed:0;

print fmt: "fd: 0x%08lx, buf: 0x%08lx, count: 0x%08lx", ((unsigned long)(REC->fd)), ((unsigned long)(REC->buf)), ((unsigned long)(REC->count))

Прикрепление программы: perf_event_open, BPF_LINK_CREATE и время жизни ссылки

Загруженная программа ещё ничего не перехватывает. Чтобы она начала исполняться, её нужно прикрепить (англ. attach) к событию. Исторически для этого использовался perf_event_open(2): ядро создавало perf_event, в него записывался дескриптор программы через ioctl(PERF_EVENT_IOC_SET_BPF), событие включалось PERF_EVENT_IOC_ENABLE. Схема работала, но имела неприятное свойство: привязка жила ровно столько, сколько жил дескриптор perf_event, а сам дескриптор был привязан к процессу-владельцу ⁶.

Начиная с ядра 5.7 появился системный вызов-команда BPF_LINK_CREATE (команда bpf() с номером 28). Ссылка (struct bpf_link) — самостоятельный объект ядра, который держит привязку независимо от того, открыт ли дескриптор perf_event, и, что важнее, может быть закреплён в /sys/fs/bpf через BPF_OBJ_PIN. Именно это превращает eBPF-трейсер из «пока крутится мой процесс» в постоянное присутствие в ядре.

union bpf_attr attr = {
    .link_create.prog_fd        = prog_fd,
    .link_create.target_fd      = perf_fd,   /* или 0 для fentry по BTF-id */
    .link_create.attach_type    = BPF_PERF_EVENT,
    .link_create.flags          = 0,
};
int link_fd = syscall(__NR_bpf, BPF_LINK_CREATE, &attr, sizeof(attr));
if (link_fd < 0) { perror("BPF_LINK_CREATE"); return 1; }

Для fentry/fexit привязка идёт не через perf_event, а через BTF-идентификатор функции: в link_create заполняются attach_btf_id и attach_btf_obj_fd. Ядро само находит нужный трамплин, и программа начинает вызываться при входе в функцию — без int3, без патча кода, без perf ⁶.

Отсюда три следствия, важные и для атакующего, и для защитника.

1. Привязка переживает процесс. Если ссылку закрепить (BPF_OBJ_PIN) в /sys/fs/bpf, она останется после завершения bpftrace, после выхода из SSH-сессии и после перезагрузки — при условии, что каталог /sys/fs/bpf смонтирован и кто-то заново открывает закреплённый объект при старте (обычно через unit-файл, см. тему 05).
2. Привязку видно в списке ссылок. bpftool link list показывает каждую ссылку с типом, идентификатором программы и целью. Программа без ссылки не работает; ссылка без закрепления умирает вместе с дескриптором. Поэтому при разборе инцидента смотрят именно ссылки, а не только программы.
3. Ссылку можно отвязать, не выгружая программу. BPF_LINK_DETACH (команда 33) разрывает привязку, оставляя программу загруженной. Обратная операция тоже возможна: закреплённую программу можно заново прикрепить к другой цели.

Виртуальная машина eBPF: регистры, стек и инструкции

Одиннадцать регистров и 512 байт стека

eBPF — не «ещё один язык», а виртуальная машина с фиксированным набором регистров и собственной системой команд. Регистров одиннадцать: r0–r10. r0 — возвращаемое значение, r1–r5 — аргументы функции и временные значения, r6–r9 — сохраняемые между вызовами, r10 — указатель на кадр стека, только для чтения.

Стек — 512 байт на программу, и он проверяется верификатором: обращение за границы, к неинициализированным байтам или по отрицательному смещению от r10 отклоняется. Это не «мягкая рекомендация», а жёсткое ограничение: программа, которая попытается прочитать 513-й байт, не загрузится.

Инструкция — 8 байт:

struct bpf_insn {
    __u8 code;        /* opcode: класс + операция */
    __u8 dst_reg:4;   /* регистр-приёмник */
    __u8 src_reg:4;   /* регистр-источник */
    __s16 off;        /* смещение для переходов и памяти */
    __s32 imm;        /* непосредственное значение */
};

Классы: BPF_LD/BPF_LDX (загрузка), BPF_ST/BPF_STX (сохранение), BPF_ALU/BPF_ALU64 (арифметика), BPF_JMP/BPF_JMP32 (переходы), BPF_CALL (вызов хелпера). Размер инструкции фиксирован — это упрощает верификатор, но исключает «переменную длину», как в x86.

BPF_PROG_LOAD и что проверяет верификатор

Программа загружается системным вызовом bpf() с командой BPF_PROG_LOAD (5) и структурой union bpf_attr, в которой: тип программы, указатель на массив инструкций, число инструкций, указатель на лицензию, указатель на журнал верификатора.

Верификатор проходит несколько стадий:

1. Разбор и проверка CFG. Каждая инструкция достижима, переходы не выходят за границы, нет «висячих» байтов.
2. Типы регистров. Для каждой точки программы известно, что лежит в регистре: скаляр с диапазоном, указатель на карту, указатель на стек, указатель на контекст.
3. Границы памяти. Обращение к карте проверяется по размеру значения, к стеку — по смещению и размеру.
4. Циклы. До ядра 5.3 циклы были запрещены полностью; с 5.3 разрешены ограниченные циклы, и верификатор доказывает, что счётчик ограничен.
5. Вызовы хелперов. Каждый хелпер имеет прототип; верификатор проверяет типы аргументов и то, что программа не вызывает запрещённые для её типа хелперы.

Отсюда класс уязвимостей, разобранный в теме 04: если верификатор ошибся в типе или границе, программа, «доказанная» безопасной, читает или пишет за пределами карты. Именно поэтому unprivileged_bpf_disabled=2 — правильная настройка по умолчанию.

Проверить, что загружено и какие программы активны, можно bpftool. Пример вывода для программы, перехватывающей read:

sudo bpftool prog list
sudo bpftool prog show id 42

42: tracepoint  name sys_enter_read  tag 3f9a2b1c4d5e6f70  gpl
	loaded_at 2026-10-19T18:20:11+0300  uid 0
	xlated 512B  jited 301B  memlock 4096B  map_ids 7,8

Читается так: тип tracepoint, имя, тег (хеш инструкций), лицензия gpl (без неё недоступны часть хелперов), время загрузки, размер до и после JIT, идентификаторы карт. По memlock видно, сколько памяти закреплено за программой.

JIT и почему это важно для обнаружения

Без JIT программа интерпретируется ядром; с JIT (CONFIG_BPF_JIT, включён по умолчанию) компилируется в машинный код. Для обнаружения это означает: в памяти ядра появляется исполняемая страница с кодом, а в kallsyms — символы вида bpf_prog_<tag>.

grep -c 'bpf_prog_' /proc/kallsyms
cat /proc/sys/net/core/bpf_jit_enable
ls -l /proc/sys/net/core/bpf_jit_harden
cat /proc/sys/net/core/bpf_jit_harden

471
1
-rw------- 1 root root 0 окт 19 18:40 /proc/sys/net/core/bpf_jit_harden
cat: /proc/sys/net/core/bpf_jit_harden: Отказано в доступе

bpf_jit_enable = 1 — JIT включён. Параметр bpf_jit_harden существует, но имеет права 0600: прочитать его может только суперпользователь. Само по себе это диагностический признак — администратор видит, что настройка есть, но её значение скрыто от непривилегированного процесса. Значение 2 означало бы, что «затвердевание» включено: константы в машинном коде заменяются на вычисляемые, и поиск программ по байтовым сигнатурам усложняется.

Число 471 — общее количество символов bpf_prog_ в таблице, включая встроенные программы подсистем, поэтому само по себе оно ничего не доказывает. Для защитника это означает, что искать программу по байтам бесполезно — надо смотреть метаданные: bpftool prog list, карты, ссылки.

Карты: типы и команды

Карты — единственный способ сохранить состояние между вызовами программы. Основные типы:

Команды bpf() для карт: BPF_MAP_CREATE (0), BPF_MAP_LOOKUP_ELEM (1), BPF_MAP_UPDATE_ELEM (2), BPF_MAP_DELETE_ELEM (3), BPF_MAP_GET_NEXT_KEY (4). Плюс BPF_OBJ_PIN (6) и BPF_OBJ_GET (7) — закрепление в /sys/fs/bpf, о котором ниже.

Почему карты вообще нужны, если есть стек? Потому что стек живёт ровно один вызов программы. Между sys_enter_read и sys_exit_read программа исполняется дважды, и во второй раз стека от первого вызова уже нет. Все данные, которые нужно пронести через границу вызовов, обязаны лежать в карте. Это же ограничение диктует форму шпионских программ: адрес буфера запоминается на входе в карту, а читается на выходе из неё.

Кольцевой буфер (BPF_MAP_TYPE_RINGBUF, ядро 5.8+) устроен иначе, чем PERF_EVENT_ARRAY: это единый буфер, разделённый между ядром и пользователем, с двумя указателями — producer и consumer. Программа резервирует область (bpf_ringbuf_reserve), заполняет её и публикует (bpf_ringbuf_submit); пользователь читает через mmap, без системного вызова на каждое событие. Порядок публикации обеспечивается барьером памяти внутри submit, поэтому читатель никогда не увидит частично заполненную запись. Отсюда два следствия: буфер быстрее perf в разы, и при переполнении он теряет события, а не блокирует программу — резерв возвращает NULL.

Пример вывода bpftool для карты, накопленной шпионом:

sudo bpftool map list
sudo bpftool map dump id 7

7: hash  name events  flags 0x0
	key 4B  value 32B  max_entries 1024  memlock 81920B
key: 00 00 00 00  value: 01 00 00 00 ...

key 4B value 32B max_entries 1024 — это и есть «что и сколько хранит программа». Для разбора инцидента карта часто важнее самой программы: в ней остаются собранные данные.

BTF и CO-RE: как программа узнаёт структуры ядра

BTF (BPF Type Format) — описание типов, встроенное в ядро (.BTF) и в программы. Оно позволяет писать bpf_probe_read_kernel(&pid, sizeof(pid), &task->pid) без знания смещения: смещение вычисляется по BTF и переносится между версиями ядра — это и есть CO-RE (Compile Once, Run Everywhere).

Формат BTF — это не «магия» и не закрытый бинарный формат. Заголовок содержит смещения и длины двух блоков: таблицы типов и таблицы строк. Прочитать его можно любым языком, и это лучший способ понять, откуда берутся смещения полей:

import struct
raw = open("/sys/kernel/btf/vmlinux", "rb").read()
magic, ver, flags, hdr_len, type_off, type_len, str_off, str_len = \
    struct.unpack("<HBBIIIII", raw[:24])
print(f"magic=0x{magic:x} version={ver} hdr_len={hdr_len}")
print(f"типов={type_len} байт, строк={str_len} байт, файл={len(raw)} байт")

magic=0xeb9f version=1 hdr_len=24
типов=3680640 байт, строк=2697421 байт, файл=6378085 байт

Каждая запись таблицы типов начинается с трёх полей: смещение имени в таблице строк, 32-битное слово info (в нём упакованы вид типа и число элементов) и поле размера. Обойдя таблицу, можно найти любую структуру ядра и её поля — именно это и делает bpftool btf dump, только на C и с генерацией заголовка ⁷:

файл BTF: 6378085 байт, типов: 143964
struct task_struct: id=131625 size=6144 байт, полей=268
  tasks        смещение  2664 байт (0xa68)
  mm           смещение  2744 байт (0xab8)
  pid          смещение  2872 байт (0xb38)
  tgid         смещение  2876 байт (0xb3c)
  parent       смещение  2896 байт (0xb50)
  real_cred    смещение  3384 байт (0xd38)
  cred         смещение  3392 байт (0xd40)
  comm         смещение  3408 байт (0xd50)

Читается это так: task_struct в этом ядре занимает 6144 байта и содержит 268 полей; поле cred лежит по смещению 0xd40, а comm — по 0xd50, сразу за ним. Именно эти числа подставляет CO-RE, когда в исходнике написано task->cred: компилятор оставляет релокацию с именем поля, а libbpf при загрузке находит тип в BTF ядра и подставляет актуальное смещение.

Практическое следствие: программа на CO-RE не ломается при обновлении ядра, а значит «обновление ядра» не является защитой от неё. Защита — только права и запрет загрузки.

Сборка программы: clang, libbpf и скелет

Программа eBPF пишется на C, но компилируется не в машинный код целевого процессора, а в байткод виртуальной машины. Отсюда отдельный таргет компилятора и отдельный набор заголовков:

clang -O2 -g -target bpf -D__TARGET_ARCH_x86 \
      -I/usr/include/bpf -c sniffer.bpf.c -o sniffer.bpf.o
llvm-strip -g sniffer.bpf.o

Флаг -g обязателен: он заставляет clang записать в объектный файл BTF-описание типов, без которого CO-RE-релокации не применятся. -D__TARGET_ARCH_x86 подставляет нужные определения регистров в vmlinux.h. llvm-strip -g убирает отладочную информацию, но сохраняет BTF — объект получается компактнее, а релокации работают.

Сама программа — это функция с секцией, имя которой определяет тип:

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 1 << 16);
} events SEC(".maps");

SEC("tracepoint/syscalls/sys_enter_read")
int on_read(struct trace_event_raw_sys_enter *ctx)
{
    struct event *e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);
    if (!e)
        return 0;                      /* буфер полон — тихо выходим */
    e->pid  = bpf_get_current_pid_tgid() >> 32;
    e->fd   = (int)ctx->args[0];
    bpf_get_current_comm(&e->comm, sizeof(e->comm));
    bpf_ringbuf_submit(e, 0);
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

Три вещи здесь неочевидны. Во-первых, SEC() — не декоративная аннотация: имя секции tracepoint/syscalls/sys_enter_read разбирается загрузчиком и превращается в пару «тип программы + цель привязки». Ошибка в одной букве даёт программу, которая загрузится, но не привяжется. Во-вторых, bpf_ringbuf_reserve может вернуть NULL, и это не ошибка, а нормальный режим переполнения: правильная программа выходит, а не пишет в пустоту. В-третьих, лицензия GPL объявлена отдельной секцией и проверяется ядром: без неё часть хелперов, включая работу с kprobe, недоступна, и программа не загрузится с EACCES.

Дальше libbpf собирает всё вместе. Утилита bpftool gen skeleton превращает объектный файл в C-заголовок со структурами и функциями открытия, загрузки и привязки:

bpftool gen skeleton sniffer.bpf.o > sniffer.skel.h

В пользовательской части остаётся три вызова:

struct sniffer_bpf *skel = sniffer_bpf__open_and_load();
if (!skel) { fprintf(stderr, "load failed\n"); return 1; }
if (sniffer_bpf__attach(skel)) { fprintf(stderr, "attach failed\n"); return 1; }
/* ... цикл чтения ringbuf ... */
sniffer_bpf__destroy(skel);

Скелет снимает с автора всю рутину: BPF_PROG_LOAD, создание карт, применение релокаций, привязку. Именно поэтому eBPF-шпион на libbpf — это два файла и Makefile, а не тысяча строк на голых системных вызовах. И именно поэтому защитнику бессмысленно искать «подозрительный бинарник»: такой трейсер выглядит как обычная утилита на C, собранная штатным компилятором ⁶.

Перехват системного вызова read и клавиатурного ввода

Трассировка sys_enter_read и sys_exit_read

Классической задачей наступательного или оборонительного мониторинга является слежка за вводом команд и паролей в терминале. В операционной системе Linux пользовательский ввод из псевдотерминала (/dev/pts/*) поступает в интерактивную командную оболочку bash посредством системного вызова read с дескриптором файла 0 (стандартный поток ввода stdin) ¹.

При входе в системный вызов (sys_enter_read) буфер назначения buf ещё пуст: ядро только начинает операцию. Поэтому фиксация прочитанных данных требует связки двух перехватчиков ²:

1. В точке sys_enter_read запоминается соответствие текущего потока (pid_tgid), дескриптора fd и виртуального адреса буфера buf (сохраняется во временной карте BPF_MAP_TYPE_HASH).
2. В точке sys_exit_read анализируется возвращаемое значение (args->ret). Если прочитано положительное число байт, eBPF-программа извлекает адрес сохранённого буфера и с помощью функции-помощника bpf_probe_read_user() копирует байты из пространства памяти процесса в карту для отправки шпиону.

Невидимый кейлоггинг на уровне ядра

Для быстрого прототипирования eBPF-шпионов применяется специализированный трассировщик bpftrace, синтаксис которого напоминает утилиту awk ³.

Рассмотрим скрипт перехвата ввода для оболочки bash:

tracepoint:syscalls:sys_enter_read
/comm == "bash"/
{
    @buffers[tid] = args.buf;
}

tracepoint:syscalls:sys_exit_read
/@buffers[tid]/
{
    $len = args.ret;
    if ($len > 0) {
        printf("[KEYLOGGER PID %d] Ввод: %s\n", pid, str(@buffers[tid], $len));
    }
    delete(@buffers[tid]);
}

Ключевое свойство такой слежки: перехват выполняется на уровне ядра без малейшей модификации исполняемого файла /bin/bash или разделяемой библиотеки libc.so.6. В пространстве пользователя отсутствуют какие-либо артефакты:

• Таблица процессов ps -ef не показывает сторонних потоков внутри оболочки;
• Список открытых дескрипторов lsof -p <PID> не содержит сокетов или файлов шпиона;
• Переменные окружения процесса (LD_PRELOAD) остаются абсолютно чистыми ⁵.

uprobe на readline: перехват командной строки целиком

Перехват read даёт поток байтов — сырой, дроблёный, с эхо-повторами и escape-последовательностями от стрелок и Tab. Строка, которую человек набрал, собирается из этих байтов только внутри самой оболочки. Значит, есть точка точнее: функция readline(), которая возвращает уже готовую строку.

Тонкость, на которой спотыкаются почти все: в bash символ readline не определён, он импортируется из разделяемой библиотеки. Проверяется одной командой:

ldd /bin/bash | grep readline
nm -D /bin/bash | grep -w readline

	libreadline.so.8 => /usr/lib/libreadline.so.8 (0x00007f4dce791000)
                 U readline

Буква U в выводе nm означает undefined — символ будет разрешён динамическим загрузчиком. Поэтому uprobe:/bin/bash:readline не сработает, а uprobe:/usr/lib/libreadline.so.8:readline — сработает, причём сразу для всех процессов, которые эту библиотеку загрузили ⁶:

uretprobe:/usr/lib/libreadline.so.8:readline
/comm == "bash"/
{
    $line = retval;
    if ($line != 0) {
        printf("[CMD %s pid=%d] %s\n", comm, pid, str($line));
    }
}

uretprobe — перехват на выходе из функции, поэтому retval уже содержит указатель на готовую строку. Функция возвращает char *, который живёт в куче процесса; str() в bpftrace разыменовывает его через bpf_probe_read_user_str(), безопасно копируя строку в карту.

Второй важный эффект: readline вызывается не только для команд. Через неё идут строки в python3, psql, sqlite3, gdb, интерактивных оболочках mysql и redis-cli — все они линкуются с libreadline или libedit. Один хук закрывает весь интерактивный ввод на машине, независимо от того, какая программа этот ввод принимает.

Где на самом деле лежит пароль: разбор трёх случаев

Самая частая ошибка при написании такого сниффера — считать, что «перехват read = перехват пароля». Это верно не всегда, и разница между случаями принципиальна.

Случай первый: локальная аутентификация. sudo, su, passwd, login читают пароль с терминала через read() из дескриптора 0, потому что терминал отключил эхо (ECHO снят через tcsetattr). Байты идут в открытом виде, и tracepoint:syscalls:sys_enter_read с фильтром по comm даёт пароль напрямую. Это тот случай, который работает.

Случай второй: SSH-сессия, пароль вводится в sudo. Здесь всё ещё работает: sudo внутри сессии читает с псевдотерминала /dev/pts/N, а sshd только передаёт байты. Фильтр по comm == "sudo" ловит ввод. Тот же приём ловит пароль, который человек печатает в passwd при смене пароля, — и это ровно то, что нужно защищать.

Случай третий: пароль вводится в sshd при аутентификации. Здесь приём не работает, и вот почему. sshd вызывает read() на сетевом сокете и получает шифротекст: расшифровка происходит позже, в пространстве пользователя, внутри функций работы с пакетами SSH. К моменту, когда в памяти появляется открытый пароль, read() уже давно вернулся. Перехват sys_enter_read для comm == "sshd" покажет поток зашифрованных байтов — бесполезный для атакующего и успокаивающий для защитника.

Открытый пароль в этом случае существует только как аргумент функции проверки подлинности внутри sshd. Значит, для него нужен либо uprobe на конкретную функцию модуля аутентификации (у каждой версии OpenSSH своя, и она меняется), либо чтение памяти процесса — приём из темы 09. Это хороший пример общего правила: чем выше уровень абстракции, тем стабильнее хук и тем меньше в нём смысла. tracepoint на read стабилен, но даёт сырые байты; uprobe на внутреннюю функцию даёт готовый секрет, но ломается при каждом обновлении пакета.

Извлечение конфиденциальных данных и фильтрация

В реальных сценариях перехватчик фильтрует поток событий, чтобы не переполнять кольцевой буфер служебными данными (чтение конфигурационных файлов, скриптов автодополнения). Фильтрация осуществляется проверкой дескриптора файла: интерес представляет исключительно fd == 0 (стандартный ввод терминала), либо чтение из символьных устройств консоли.

Кроме того, eBPF-программа может определять контекст родительского процесса через внутреннюю структуру ядра task_struct, выявляя моменты аутентификации через sudo или su ¹.

Прямые системные вызовы в архитектуре x86_64

Анатомия перехода: инструкция syscall и регистры

Традиционно программы для Linux не выполняют системные вызовы напрямую. Вместо этого прикладной код вызывает обёртку в стандартной библиотеке C: read(), write(), openat(). Обёртка подготавливает аргументы и выполняет инструкцию перехода в ядро ¹. Такое разделение отражает классическую философию проектирования UNIX, согласно которой прикладное ПО изолировано от прямого управления низкоуровневыми аппаратными структурами ⁴.

В 64-битной архитектуре x86_64 переход в ring0 осуществляется специализированной инструкцией процессора syscall. При её выполнении процессор сохраняет текущий адрес возврата в регистре %rcx, флаги процессора %rflags — в регистре %r11, после чего переключает уровень привилегий на уровень ядра и передаёт управление по адресу, сохранённому в специальном машинном регистре MSR_LSTAR ².

Конвенция системных вызовов Linux на архитектуре x86_64 строго регламентирует использование регистров:

На рисунке 2 проиллюстрировано принципиальное отличие библиотечного вызова от прямого обращения к ядру.

Таблица номеров системных вызовов в unistd_64.h

Каждому системному вызову в ядре сопоставлен целочисленный номер. В системах Linux для архитектуры x86_64 каноническая таблица номеров зафиксирована в системном заголовочном файле /usr/include/asm/unistd_64.h ².

Исследуем содержимое таблицы номеров системных вызовов с помощью утилит командной строки:

grep -E '__NR_(read|write|open|close|execve|bpf)\b' /usr/include/asm/unistd_64.h

#define __NR_read 0
#define __NR_write 1
#define __NR_open 2
#define __NR_close 3
#define __NR_execve 59
#define __NR_bpf 321

Как видно из заголовка, вызов read имеет номер 0, write — 1, а системный вызов bpf — 321.

Функция syscall() и реализация на встроенном ассемблере

В языке C выполнить системный вызов в обход стандартной обёртки функции можно двумя путями: с помощью функции syscall(long number, ...) из <unistd.h>, либо непосредственно через блок встроенного ассемблера __asm__ volatile ¹.

Реализуем чтение из стандартного ввода с помощью ассемблерной вставки:

#define _GNU_SOURCE
#include <unistd.h>
#include <stddef.h>

long asm_sys_read(int fd, void *buf, size_t count) {
    long ret;
    __asm__ volatile (
        "movq $0, %%rax\n\t"        /* Номер __NR_read = 0 */
        "movq %1, %%rdi\n\t"        /* arg1: fd */
        "movq %2, %%rsi\n\t"        /* arg2: buf */
        "movq %3, %%rdx\n\t"        /* arg3: count */
        "syscall\n\t"               /* Инструкция перехода в ring0 */
        "movq %%rax, %0\n\t"        /* Сохранение возвращаемого значения */
        : "=r"(ret)
        : "r"((long)fd), "r"(buf), "r"((long)count)
        : "rax", "rdi", "rsi", "rdx", "rcx", "r11", "memory"
    );
    return ret;
}

Обратите внимание на список разрушаемых регистров (clobber list): в нём обязательно указываются "rcx" и "r11", так как процессорная инструкция syscall модифицирует их аппаратно при сохранении контекста ².

Программа без libc: -nostdlib и собственная точка входа

Ассемблерная вставка убирает вызов библиотечной обёртки, но сама программа всё ещё слинкована с libc: загрузчик подгружает её, конструкторы выполняются, main вызывается из __libc_start_main. Для полного разрыва с пользовательской библиотекой собирают статический бинарник без стандартного старта:

gcc -nostdlib -static -O2 -o naked naked.c

В таком файле нет ни main, ни __libc_start_main: точкой входа служит _start, а всё, что нужно программе, она делает сама. Проверить это можно по таблице символов и по списку зависимостей:

LC_ALL=C readelf -h naked | grep 'Entry point'
LC_ALL=C readelf -d naked 2>/dev/null | grep NEEDED || echo "нет зависимостей от .so"

  Entry point address:               0x401000
нет зависимостей от .so

Пустая таблица NEEDED означает, что динамическому загрузчику в этом файле делать нечего: ld.so не участвует в запуске, LD_PRELOAD не применяется, /etc/ld.so.preload не читается. Для перехватчика в пространстве пользователя такой процесс — чёрный ящик: подменить в нём нечего, потому что подменять нечего.

Полная программа, которая печатает строку и завершается, без единого библиотечного вызова, выглядит так:

/* naked.c — сборка: gcc -nostdlib -static -O2 -o naked naked.c */
#define SYS_write 1
#define SYS_exit  60

static long raw_syscall3(long n, long a, long b, long c)
{
    long ret;
    __asm__ volatile ("syscall"
        : "=a"(ret)
        : "a"(n), "D"(a), "S"(b), "d"(c)
        : "rcx", "r11", "memory");
    return ret;
}

void _start(void)
{
    static const char msg[] = "naked binary: no libc, no hooks\n";
    raw_syscall3(SYS_write, 1, (long)msg, sizeof(msg) - 1);
    raw_syscall3(SYS_exit, 0, 0, 0);
    __builtin_unreachable();
}

Здесь использованы ограничения компилятора "D", "S", "d", "a" — они кладут значения сразу в rdi, rsi, rdx, rax, избавляя от ручных movq. Это чище и короче, чем явные пересылки, и компилятор сам следит за тем, чтобы регистры не пересеклись с входными значениями.

Что прямой вызов не обходит: seccomp и eBPF

Прямой системный вызов обходит перехватчики, работающие в пространстве пользователя. Список того, что он обходит, короток и конкретен: LD_PRELOAD, /etc/ld.so.preload, inline-патчинг функций libc, ltrace, библиотечные обёртки аудита. Всё это живёт в ring3 и исчезает вместе с libc.

Список того, что он не обходит, длиннее, и его полезно знать наизусть ²:

• seccomp-фильтры. Фильтр seccomp проверяет номер системного вызова и аргументы в момент входа в ядро, до выполнения обработчика. Путь до инструкции syscall не имеет значения: read есть read, откуда бы он ни пришёл.
• ptrace и strace. Трассировщик останавливает процесс на входе в системный вызов через PTRACE_SYSCALL, и это происходит уже после перехода в ring0.
• auditd. Правила аудита на системные вызовы (-a always,exit -F arch=b64 -S openat) срабатывают в ядре, в общей точке входа.
• eBPF-трейсеры. Точка tracepoint:syscalls:sys_enter_read находится внутри entry_SYSCALL_64, ниже любого пользовательского кода.
• LSM-хуки. Yama, AppArmor, SELinux вызываются из ядра по факту операции, а не по факту библиотечного вызова.

Практический вывод: прямой системный вызов — это инструмент против пользовательских хуков, а не против ядерных. В модели угроз, где защита ставит eBPF-трейсер (а современные EDR на Linux делают именно это), прямой вызов не даёт ничего: операция всё равно видна. Его настоящая ценность в другом — он гарантирует, что операция выполнится, даже если все разделяемые библиотеки в процессе подменены, и он не оставляет в процессе следов в виде загруженных хуков.

Обход перехватчиков пространства пользователя (EDR и LD_PRELOAD)

Механизм user-mode хукинга и инспекции

Большинство систем защиты рабочих станций (EDR) и программ мониторинга для Linux функционируют в пространстве пользователя. Они используют один из двух методов перехвата ¹:

1. Динамическая подмена (shim): использование переменной окружения LD_PRELOAD или конфигурационного файла /etc/ld.so.preload для подмены функций libc (read, connect, execve).
2. Патчинг в памяти (Inline Hooking): модификация пролога функции в оперативной памяти процесса — первые 5 байт библиотечной функции перезаписываются инструкцией безусловного перехода jmp на инспекционный обработчик защитного агента.

Когда приложение вызывает read(0, buf, size), управление попадает в обработчик EDR. Агент безопасности анализирует аргументы, проверяет контекст выполнения и принимает решение о блокировке или передаче управления оригинальному системному коду.

Почему прямые вызовы невидимы для библиотечных перехватов

Прямой системный вызов полностью ломает логику user-mode хукинга. Поскольку инструкция syscall выполняется непосредственно из сегмента кода исполняемого файла программы, поток управления вообще не обращается к библиотеке libc.so.6.

В таблице представлено поведение механизмов мониторинга при различных методах вызова:

Таким образом, прямые системные вызовы гарантируют выполнение операции даже в том случае, если все разделяемые библиотеки в процессе были модифицированы или скомпрометированы средствами аудита пользовательского пространства ¹.

Проверка на практике: три инструмента на одном бинарнике

Таблицу выше легко проверить, не полагаясь на веру. Соберём программу, которая читает из стандартного ввода двумя способами — через библиотечную обёртку и через syscall():

#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <stdio.h>

int main(void)
{
    char b[8];
    ssize_t n1 = read(0, b, sizeof b);              /* путь 1: libc */
    ssize_t n2 = syscall(SYS_read, 0, b, sizeof b); /* путь 2: напрямую */
    printf("%zd %zd\n", n1, n2);
    return 0;
}

Заголовок <sys/syscall.h> здесь обязателен: константа SYS_read определена в нём, а не в <unistd.h>. Без него компилятор выдаст «SYS_read не описан», и это первая ошибка, которую делает каждый.

Теперь ltrace, который перехватывает вызовы разделяемых библиотек:

printf 'ab\n' | ltrace -e 'read+syscall' ./cmp

cmp->read(0, "ab\n", 8)                          = 3
cmp->syscall(0, 0, 0x7ffd32fa2440, 8)            = 0

Видно ровно то, что и должно быть видно: read показан с аргументами и результатом, а syscall — как непрозрачный вызов с номером 0 в первом аргументе. ltrace не знает, что номер 0 означает read: для него это просто число. Первый вывод: библиотечный трассировщик видит обёртку, но не видит смысла прямого вызова.

Тот же бинарник под strace, который работает через ptrace и системные вызовы:

printf 'ab\n' | strace -e trace=read ./cmp

read(0, "ab\n", 8)                      = 3
read(0, "", 8)                          = 0

Обе операции выглядят одинаково: два вызова read с одинаковыми аргументами. Для ядра разницы между путями нет вообще. Второй вывод: ядерный трассировщик видит оба пути и не может отличить их по сисколлу.

Третий инструмент — LD_PRELOAD-шим, который подменяет read и логирует чтение с дескриптора 0:

#define _GNU_SOURCE
#include <dlfcn.h>
#include <unistd.h>
#include <stdio.h>

ssize_t read(int fd, void *buf, size_t count)
{
    static ssize_t (*real)(int, void *, size_t) = NULL;
    if (!real)
        real = dlsym(RTLD_NEXT, "read");
    ssize_t n = real(fd, buf, count);
    if (fd == 0 && n > 0)
        fprintf(stderr, "[SHIM] fd=0 bytes=%zd data=\"%.*s\"\n",
                n, (int)(n > 32 ? 32 : n), (char *)buf);
    return n;
}

gcc -shared -fPIC -O1 -o shim.so shim.c -ldl
printf 'secret\n' | LD_PRELOAD=./shim.so ./cmp

[SHIM] fd=0 bytes=7 data="secret
"
7 0

Шим сработал на первом read — библиотечном — и промолчал на втором, прямом. Обратите внимание на результат 7 0: первый вызов прочитал все семь байт, второй получил 0, то есть конец файла. Данные ушли в первый вызов, и шим их увидел; второй вызов был пустым.

Чтобы картина была полной, применим тот же шим к статическому бинарнику без libc:

LD_PRELOAD=./shim.so ./naked

naked binary: no libc, no hooks

Ни одной строки [SHIM]. Подмены нет не потому, что программа «защитилась», а потому, что подменять нечего: в файле нет таблицы импорта, и LD_PRELOAD не к чему применить. Третий вывод: чем меньше в программе пользовательской библиотеки, тем меньше в ней точек перехвата.

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

Несмотря на эффективность против EDR в user-space, прямой системный вызов невозможно скрыть от подсистем ядра Linux. Независимо от того, откуда была выполнена инструкция syscall — из библиотеки libc или из рукописного ассемблерного блока — процессор неизбежно переключается в ring0 и выполняет обработчик ядра entry_SYSCALL_64 ².

В этот момент активируются статические точки трассировки tracepoint:syscalls:sys_enter_* и подсистема eBPF. Для ядра не имеет значения, какой путь прошла программа до выполнения инструкции syscall: аргументы в регистрах RAX, RDI, RSI считываются одинаково надёжно.

Обнаружение eBPF-шпионов и форензика ядра

Что администратор видит до всяких утилит

Прежде чем запускать bpftool, полезно понять, какие следы присутствия eBPF вообще существуют на голой системе. Их немного, и они устойчивы.

Счётчик символов в kallsyms. Каждая JIT-скомпилированная программа получает в таблице символов ядра имя вида bpf_prog_<тег>. Символы присутствуют всегда, даже когда адреса скрыты:

grep -c 'bpf_prog_' /proc/kallsyms
grep -E ' (__x64_sys_bpf|entry_SYSCALL_64)$' /proc/kallsyms

471
0000000000000000 T entry_SYSCALL_64
0000000000000000 T __x64_sys_bpf

Читается так: в этом ядре 471 символ с префиксом bpf_prog_ — это встроенные программы подсистем (cgroup, bpfilter, трассировщики perf), а не чьи-то шпионы. Адреса нулевые, потому что kptr_restrict не равен нулю и у процесса нет прав: таблица символов отдаётся без адресов. Практический вывод: считать символы бессмысленно, их всегда сотни. Искать надо аномалию — например, программу с тегом, которая появилась между двумя снимками kallsyms и не соответствует ни одному пакету.

Состояние подсистемы. Четыре параметра описывают, насколько eBPF вообще открыт на этой машине:

for f in kernel.unprivileged_bpf_disabled net.core.bpf_jit_enable \
         kernel.perf_event_paranoid; do
    printf '%s = %s\n' "$f" "$(cat /proc/sys/$(echo $f | tr . /))"
done

kernel.unprivileged_bpf_disabled = 2
net.core.bpf_jit_enable = 1
kernel.perf_event_paranoid = 2

Разбор: unprivileged_bpf_disabled = 2 — загрузка eBPF запрещена всем, кроме процессов с CAP_BPF, и параметр нельзя вернуть в 0 без перезагрузки (только 1 или 2). bpf_jit_enable = 1 — JIT включён, программы компилируются в машинный код. perf_event_paranoid = 2 — непривилегированный perf не может создавать большинство событий, что закрывает и perf_event_open как путь к привязке.

Четвёртый параметр, bpf_jit_harden, в этот список не попал намеренно: у него права 0600, и непривилегированный процесс получает отказ в доступе, а не значение. Для снимка состояния это важно различать: «параметр скрыт» и «параметр равен нулю» — разные факты, и второй из первого не следует.

Режим блокировки. Отдельный механизм, который запрещает kprobe целиком:

cat /sys/kernel/security/lockdown 2>/dev/null

[none] integrity confidentiality

В квадратных скобках — активный режим. [none] означает, что блокировки нет: kprobe разрешены. В режиме confidentiality ядро отказывает в привязке kprobe и в чтении памяти ядра, и половина приёмов этой темы перестаёт работать даже у суперпользователя ⁸.

Права процесса. Самая частая причина, по которой «ничего не работает»:

grep -E 'Cap(Eff|Bnd)' /proc/self/status

CapEff:	0000000000000000
CapBnd:	0000000000000000

Пустые наборы означают, что у процесса нет ни одной возможности, включая CAP_BPF и CAP_SYS_ADMIN. В такой оболочке не запустится ни bpftrace, ни bpftool, ни собственный загрузчик программ:

bpftrace -e 'tracepoint:syscalls:sys_enter_read { printf("x\n"); }'

ERROR: Missing CAP_DAC_READ_SEARCH capability, please run bpftrace as the root user.

Это не ошибка установки и не баг: bpftrace честно сообщает, что для доступа к tracefs и загрузки программ нужны права. Именно поэтому все эксперименты с загрузкой eBPF в этой теме выполняются в виртуальной машине с полными правами, а на рабочей системе проверяются только наблюдаемые параметры.

Инспекция загруженных программ через bpftool

Поскольку eBPF работает в ядре, администратор системы располагает штатными средствами аудита для выявления несанкционированных трейсеров. Основной утилитой для управления подсистемой BPF в дистрибутивах Linux является bpftool ³.

Схема аудита ядра администратором приведена на рисунке 3.

Выведем список всех загруженных в ядро программ eBPF с помощью команды bpftool prog show. Пример вывода:

sudo bpftool prog show

124: tracepoint  name sys_enter_read  tag 8f4a13b0c41189a1  gpl
	loaded_at 2026-10-19T14:15:20+0000  uid 0
	xlated 144B  jited 96B  memlock 4096B  map_ids 42
125: tracepoint  name sys_exit_read   tag 1c890abf44ef2281  gpl
	loaded_at 2026-10-19T14:15:20+0000  uid 0
	xlated 216B  jited 136B  memlock 4096B  map_ids 42

В выводе команды отражаются ключевые характеристики программы:

• Числовой идентификатор ID программы (124, 125);
• Тип программы (tracepoint, kprobe);
• Имя программы и её криптографический тег байткода tag;
• Идентификаторы ассоциированных карт памяти (map_ids 42).

Инспекция карт памяти позволяет обнаружить буферы, в которые шпион накапливает перехваченную информацию. Пример вывода:

sudo bpftool map show id 42

42: hash  name buffers  flags 0x0
	key_size 4B  value_size 8B  max_entries 10240  memlock 823296B

Файловая система /sys/fs/bpf и закрепление программ

В штатном режиме программа eBPF выгружается из ядра автоматически, как только закрывается последний дескриптор файла процесса, создавшего её (например, при завершении скрипта bpftrace).

Чтобы обеспечить долговременное присутствие (персистентность) без работающего процесса в user-space, программы привязывают (англ. pinning) к специальной псевдофайловой системе bpf, монтируемой в /sys/fs/bpf ². Проверить наличие закреплённых объектов можно стандартными командами:

ls -la /sys/fs/bpf

total 0
drwxr-xr-x 2 root root 0 Oct 19 14:00 .
drwxr-xr-x 9 root root 0 Oct 19 14:00 ..
-rw------- 1 root root 0 Oct 19 14:10 tracer_prog
-rw------- 1 root root 0 Oct 19 14:10 stolen_keys_map

Обнаружение посторонних объектов в каталоге /sys/fs/bpf является прямым индикатором компрометации (IoC) системы на уровне ядра ³.

Защита ядра: блокировка bpf без привилегий и lockdown

Для предотвращения несанкционированного использования eBPF в операционных системах Linux предусмотрен комплекс защитных мер ⁸:

1. Запрет непривилегированного BPF: системный параметр kernel.unprivileged_bpf_disabled запрещает вызов bpf() процессам без прав CAP_BPF или CAP_SYS_ADMIN:

sudo sysctl -w kernel.unprivileged_bpf_disabled=1

kernel.unprivileged_bpf_disabled = 1

Значение 2 (как на машине, где снимались измерения выше) означает, что параметр зафиксирован до перезагрузки и не может быть ослаблен обратно в 0 — только 1 или 2. Это важно: атакующий с временным root не сможет «вернуть как было» одним sysctl -w.

2. JIT Hardening: параметр net.core.bpf_jit_harden=2 включает «затвердевание» машинного кода — константы заменяются на вычисляемые значения, что затрудняет поиск программ по байтовым сигнатурам и атаки класса JIT-spray. Настройка требует сборки ядра с соответствующей опцией; если параметра нет в /proc/sys/net/core, опция не включена.

3. Режим Kernel Lockdown: в режиме lockdown=confidentiality ядро запрещает привязку kprobes и чтение памяти ядра даже суперпользователю. Проверяется чтением /sys/kernel/security/lockdown; активный режим выделен квадратными скобками.

4. Изоляция прав: вместо CAP_SYS_ADMIN выдавать CAP_BPF и CAP_PERFMON — они покрывают загрузку программ и работу с perf, но не дают доступа к остальной административной поверхности. Для контейнеров — запрет CAP_BPF в профиле и no-new-privileges.

5. Аудит загрузки программ: правило auditd на системный вызов bpf фиксирует каждый факт загрузки и привязки с указанием процесса и его прав:

sudo auditctl -a always,exit -F arch=b64 -S bpf -k bpf_load
sudo ausearch -k bpf_load -i | tail -20

Правило срабатывает на все команды bpf(), поэтому в журнале будут и легитимные вызовы системных служб. Практический приём — не читать журнал целиком, а искать записи, у которых comm не входит в белый список: bpftrace, systemd, NetworkManager, sshd и подобные.

Матрица «приём — признак — контрмера»

Сведём разобранные приёмы в одну таблицу. Она же — основа отчёта при разборе инцидента.

Из таблицы видно главное: ни один приём не является невидимым. Прямые вызовы невидимы для библиотечных хуков, но видны ядру; eBPF-программы невидимы для процессов, но видны в подсистеме BPF. Разница только в том, кто именно смотрит и на каком уровне. Отсюда практическое правило защитника: смотреть надо не на процессы, а на подсистемы — на список программ, список ссылок, закреплённые объекты и журнал загрузки. И ещё одно: любое обнаружение опирается на снимок до инцидента. Без baseline список из 471 символа bpf_prog_ бесполезен, а с baseline появление нового тега между двумя снимками — готовый индикатор.

Итоги темы

В рамках данной темы было исследовано противостояние механизмов мониторинга и техник обхода на границе пространства пользователя и ядра Linux. Использование прямых системных вызовов позволяет приложениям полностью исключить обращение к разделяемым библиотекам, делая операции невидимыми для перехватчиков LD_PRELOAD и user-mode EDR. Архитектура x86_64 обеспечивает строгую конвенцию передачи параметров через регистры и атомарный переход в ring0 с помощью инструкции syscall.

Проверка на практике расставила границы этого обхода точнее, чем любая таблица: ltrace видит библиотечный read и не видит смысла в syscall(0, ...), strace видит оба вызова одинаково, а LD_PRELOAD-шим срабатывает на первом и молчит на втором. Статический бинарник без libc вообще не оставляет точки для подмены. Но ядро остаётся на месте: seccomp, auditd, LSM и eBPF-точки трассировки срабатывают ниже уровня пользователя, и обойти их прямым вызовом невозможно.

С другой стороны, подсистема eBPF предоставляет администраторам и исследователям мощный инструмент тотальной трассировки. Виртуальная машина с одиннадцатью регистрами и 512 байтами стека, верификатор, JIT-компиляция, карты и CO-RE превращают ядро в программируемую среду: программа на C, собранная clang и привязанная через BPF_LINK_CREATE, перехватывает ввод-вывод процессов, не оставляя следов в их адресном пространстве. При этом у приёма есть цена: программа живёт в подсистеме BPF и потому видна там, а bpftrace без CAP_BPF не запускается вовсе.

Форензик-анализ присутствия eBPF опирается на инспекцию ядра через bpftool, мониторинг файловой системы /sys/fs/bpf и аудит системных вызовов загрузки программ. В следующей теме рассматриваются техники непосредственной модификации оперативной памяти процессов и применение механизма ptrace для внедрения кода и извлечения конфиденциальных ключей.

Литература

1. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
2. The Linux man-pages project. — https://man7.org/linux/man-pages/
3. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.
4. Raymond E. S. The Art of UNIX Programming. — Addison-Wesley, 2003. Открытая версия: http://www.catb.org/esr/writings/taoup/
5. Free Software Foundation. GNU Bash Reference Manual. — https://www.gnu.org/software/bash/manual/
6. Gregg B. BPF Performance Tools. — Addison-Wesley, 2019.
7. Bovet D. P., Cesati M. Understanding the Linux Kernel. 3rd ed. — O'Reilly Media, 2005.
8. Linux Kernel Documentation. — https://docs.kernel.org/

Дополнительные материалы

Вопросы для самопроверки

1. Чем фундаментально различаются подходы к мониторингу процессов в пространстве пользователя (user-space) и пространстве ядра (kernel-space)?
2. Какие гарантии стабильности ядра обеспечивает статический верификатор eBPF при загрузке программы?
3. В каких случаях разработчики систем защиты выбирают точки трассировки tracepoint, а в каких — зонды kprobe?
4. Почему при перехвате функции sys_read чтение данных буфера невозможно выполнить исключительно в точке sys_enter_read?
5. Для чего в подсистеме eBPF используются кольцевые буферы BPF_MAP_TYPE_RINGBUF?
6. Какая инструкция микропроцессора x86_64 осуществляет аппаратный переход в ring0 в современных 64-битных системах Linux?
7. В каком машинном регистре ядро Linux ожидает номер системного вызова при выполнении инструкции syscall?
8. Почему компилятор C использует конвенцию System V AMD64 ABI с регистром RCX для четвёртого аргумента, а ядро Linux требует регистр R10?
9. Что означает отрицательное возвращаемое значение в регистре RAX после выполнения системного вызова в ассемблерной функции?
10. Каким образом механизм LD_PRELOAD осуществляет перехват функций и почему он не затрагивает исполняемые файлы со статическим связыванием?
11. Почему программа с прямыми системными вызовами остаётся полностью прозрачной для мониторинга через eBPF?
12. Какую роль играет псевдофайловая система /sys/fs/bpf в сохранении персистентности программ ядра?

Глоссарий темы

Шпаргалка

# Поиск номера системного вызова в таблице ядра
grep -E '__NR_<имя_вызова>\b' /usr/include/asm/unistd_64.h

# Просмотр формата параметров точки трассировки
cat /sys/kernel/tracing/events/syscalls/sys_enter_<имя>/format

# Инспекция всех загруженных программ eBPF
sudo bpftool prog show

# Детальная информация о программе BPF по числовому идентификатору
sudo bpftool prog show id <ID>

# Дамп JIT-скомпилированных машинных инструкций программы ядра
sudo bpftool prog dump jited id <ID>

# Инспекция всех активных карт памяти eBPF
sudo bpftool map show

# Дамп содержимого карты BPF
sudo bpftool map dump id <ID>

# Проверка закреплённых персистентных объектов BPF
ls -la /sys/fs/bpf

# Трассировка системных вызовов конкретного процесса через strace
strace -f -e trace=read,write,bpf -p <PID>

# Запрет непривилегированного использования bpf в системе
sudo sysctl -w kernel.unprivileged_bpf_disabled=1

Соответствие регистров x86_64 при вызове ядра Linux:

• RAX — номер системного вызова (например, 0 для read, 1 для write, 59 для execve);
• RDI — 1-й аргумент;
• RSI — 2-й аргумент;
• RDX — 3-й аргумент;
• R10 — 4-й аргумент (не RCX!);
• R8 — 5-й аргумент;
• R9 — 6-й аргумент;
• RAX — код возврата (значения от -4095 до -1 сигнализируют об ошибке -errno).

Типичные ошибки

1. Использование регистра RCX для передачи 4-го аргумента системного вызова

   • Симптом: Системный вызов с четырьмя и более аргументами завершается с ошибкой EINVAL или получает некорректный указатель.
   • Причина: В конвенции функций C (System V AMD64) 4-й аргумент передаётся в RCX, однако процессорная инструкция syscall аппаратно затирает значение регистра RCX адресом возврата %rip. Ядро Linux ожидает 4-й аргумент в регистре R10.
   • Как исправить: Помещать значение 4-го параметра строго в регистр R10 (movq %rcx, %r10).

2. Неверный список разрушаемых регистров (clobber list) во встроенном ассемблере

   • Симптом: Непредсказуемые сбои программы, повреждение локальных переменных или сегфолт (SIGSEGV) после выполнения инструкции syscall.
   • Причина: Инструкция syscall модифицирует регистры RCX и R11. Если они не объявлены в списке разрушаемых регистров блока asm, компилятор gcc рассчитывает на сохранение их значений.
   • Как исправить: Всегда явно указывать "rcx", "r11", "memory" в clobber-списке ассемблерной вставки.

3. Ошибочная интерпретация кода возврата системного вызова

   • Симптом: Программа считает вызов успешным, хотя операция ядра завершилась с ошибкой.
   • Причина: При прямом системном вызове переменная errno не выставляется библиотекой автоматически. Ядро возвращает отрицательное число -errno непосредственно в регистре RAX (в диапазоне от -4095 до -1).
   • Как исправить: Проверять знаковое значение RAX: если результат отрицательный, инвертировать знак для получения значения системной ошибки.

4. Попытка загрузки eBPF-программ без необходимых привилегий

   • Симптом: Системный вызов bpf(BPF_PROG_LOAD, ...) завершается с ошибкой EPERM (Operation not permitted).
   • Причина: В современных дистрибутивах Linux загрузка программ eBPF для трассировки ядра требует прав суперпользователя либо наличия привилегий CAP_BPF / CAP_SYS_ADMIN и отключённого параметра kernel.unprivileged_bpf_disabled.
   • Как исправить: Запускать трейсер от имени пользователя root или назначить исполняемому файлу соответствующие capabilities.

5. Иллюзия сокрытия прямого системного вызова от мониторинга ядра

   • Симптом: Программа, использующая direct syscall, обнаружена и заблокирована сенсором EDR.
   • Причина: Прямой системный вызов обходит исключительно user-mode ловушки (LD_PRELOAD и хуки в libc). Сенсоры на базе eBPF работают внутри ring0 и перехватывают системный вызов на входе в ядро независимо от вызывающего кода.
   • Как исправить: Учитывать ограничения методики: прямые системные вызовы защищают от прикладных перехватчиков, но полностью видимы для мониторинга уровня ядра.

6. Отсутствие директивы _GNU_SOURCE при использовании системной функции syscall()

   • Симптом: Предупреждение компилятора implicit declaration of function ‘syscall’ или отсутствие констант SYS_*.
   • Причина: Прототип функции syscall и системные макроопределения регламентируются стандартами GNU/Linux и скрыты в стандартных заголовочных файлах без включения расширений GNU.
   • Как исправить: Поместить #define _GNU_SOURCE в самую первую строку исходного файла перед включением системных библиотек.

Что на самом деле показывает снимок состояния

Вывод baseline.sh — не «набор галочек», а четыре независимых факта, и путать их нельзя. Разберём построчно на реальном примере.

ядро = 7.2.4-zen2-1-zen
unprivileged_bpf_disabled = 2
bpf_jit_enable = 1
bpf_jit_harden = НЕТ ДОСТУПА
perf_event_paranoid = 2
lockdown = [none] integrity confidentiality
btf_vmlinux_байт = 6378085
bpf_prog_символов = 471

Главное правило работы со снимком: сравнивать, а не оценивать. Отдельное значение почти никогда не является индикатором. Индикатором становится разница между двумя снимками, снятыми до и после подозрительного события. Поэтому baseline.sh и написан так, чтобы его вывод можно было сохранить в файл и сравнить через diff, а не читать глазами.

Второе правило: различать три состояния параметра — «значение прочитано», «значение скрыто правами», «параметр отсутствует». Первое даёт факт, второе — факт о правах, третье — факт о сборке ядра. Смешивать их в одно «НЕТ» — типичная ошибка отчётности, из-за которой в журналах появляется «hardening выключен» там, где он просто не читается без root.

Анатомия BTF за пять минут

BTF — обычный бинарный формат с заголовком из восьми полей. Понимание этих полей снимает магию с CO-RE.

struct btf_header {
    __u16 magic;      /* 0xeb9f */
    __u8  version;    /* 1 */
    __u8  flags;
    __u32 hdr_len;    /* 24 */
    __u32 type_off;   /* смещение таблицы типов от конца заголовка */
    __u32 type_len;   /* длина таблицы типов */
    __u32 str_off;    /* смещение таблицы строк */
    __u32 str_len;    /* длина таблицы строк */
};

Реальные числа с проверенной машины: файл 6378085 байт, таблица типов 3680640 байт, таблица строк 2697421 байт, всего 143964 типа. Сумма блоков и заголовка даёт размер файла — это первая проверка, которую стоит делать при разборе: если не сходится, файл обрезан или это не BTF.

Каждая запись таблицы типов начинается одинаково:

struct btf_type {
    __u32 name_off;  /* смещение имени в таблице строк */
    __u32 info;      /* kind:24..28, vlen:0..15, kind_flag:31 */
    union { __u32 size; __u32 type; };
};

Поле info упаковано: младшие 16 бит — число элементов (vlen), биты 24–28 — вид типа, старший бит — флаг. Именно поэтому разбор BTF без знания структуры info невозможен: одна и та же четвёрка байтов означает и «размер структуры», и «тип указателя», в зависимости от вида.

Для структуры (kind = 4) за заголовком идёт vlen записей по 12 байт: смещение имени, тип поля и смещение в битах. Отсюда и берутся числа вида cred смещение 3392 байт (0xd40) — это смещение_в_битах / 8.

CO-RE работает так: компилятор clang при виде task->cred оставляет в объектном файле релокацию с именем поля и именем структуры, а не числовое смещение. При загрузке libbpf находит в BTF работающего ядра структуру task_struct, ищет в ней поле cred и подставляет актуальное смещение. Поэтому одна и та же собранная программа работает и на ядре, где cred лежит по 0xd40, и на ядре, где он сместился на 0xd80.

Отсюда два практических следствия. Первое: программа на CO-RE не ломается при обновлении ядра — и это не защита, а свойство. Второе: BTF обязан быть доступен на целевой машине; если ядро собрано без CONFIG_DEBUG_INFO_BTF, CO-RE-программа не загрузится с внятной ошибкой о ненайденном типе.

Три ошибки, которые стоят дороже остальных

Первая: uprobe не на тот символ. Классика — попытка привязаться к readline в /bin/bash. Символ там не определён, он импортируется из libreadline.so.8, и uprobe:/bin/bash:readline не сработает — привязка либо не найдётся, либо не вызовется ни разу. Проверяется одной командой:

nm -D /bin/bash | grep -w readline

                 U readline

Буква U — undefined. Значит, цель хука — библиотека, а не бинарник. То же правило действует для printf, malloc, SSL_read: искать надо там, где символ определён, а не там, где он вызывается.

Вторая: чтение буфера не в той точке. Сниффер, который читает buf в sys_enter_read, получает мусор: ядро ещё не выполнило чтение, в буфере лежит то, что было раньше. Правильная схема — запомнить адрес на входе, прочитать на выходе, — требует двух точек и карты. Это не «оптимизация», а единственный корректный способ.

Третья: вера в то, что прямой вызов прячет от ядра. Прямой syscall обходит LD_PRELOAD, inline-хуки и ltrace. Он не обходит strace, seccomp, auditd, LSM и eBPF. Разница между «невидим для библиотеки» и «невидим для системы» — самая дорогая ошибка в этой теме, потому что она создаёт ложное чувство защищённости у обеих сторон: атакующий считает себя скрытым, защитник считает, что всё пропустил.

Что почитать и посмотреть

1. Kerrisk M. The Linux Programming Interface (No Starch Press, 2010). Глава 3 «System Programming Concepts» — фундаментальное описание модели системных вызовов Linux, переключения контекста и обработки ошибок.
2. The Linux man-pages project (man 2 syscall, man 2 bpf, man 8 bpftool). Официальное руководство по сигнатурам системных вызовов, правилам конвенции регистров x86_64 и управлению подсистемой eBPF.
3. Nemeth E., Snyder G. et al. UNIX and Linux System Administration Handbook (5th ed., Addison-Wesley, 2017). Глава 27 об анализе производительности и мониторинге системных ресурсов в Linux.
4. Raymond E. S. The Art of UNIX Programming (Addison-Wesley, 2003). Анализ философии UNIX-систем, концепции разделения пространства ядра и прикладных процессов.
5. GNU Bash Reference Manual (https://www.gnu.org/software/bash/manual/). Раздел, посвящённый стандартным потокам ввода-вывода и обработке терминальных сессий оболочкой.
6. Документация ядра Linux: eBPF Documentation (https://docs.kernel.org/bpf/). Официальная спецификация архитектуры виртуальной машины BPF, типов карт и верификатора безопасности.
7. Gregg B. BPF Performance Tools (Addison-Wesley, 2019). Практическое руководство по bpftrace и bcc: готовые однострочники, разбор накладных расходов и методика поиска узких мест через точки трассировки.
8. Bovet D. P., Cesati M. Understanding the Linux Kernel (3rd ed., O'Reilly Media, 2005). Устройство task_struct, списков задач и структур ядра — то, что стоит прочитать перед разбором BTF-вывода.

Лабораторная работа 8. «eBPF шпион»

• Раздел курса: тема 08 «eBPF для слежки и прямые системные вызовы»

Введение

Граница между пространством пользователя и ядром — не линия на схеме, а конкретная инструкция процессора. Пока программа вызывает read() из libc, между её намерением и ядром стоит чужой код, который можно подменить. Как только она выполняет syscall сама, чужого кода нет — но и ядро никуда не исчезает.

Работа построена так, чтобы это противоречие было видно на своих руках, а не на словах. Сначала вы получите один и тот же результат двумя путями и убедитесь, что ltrace видит только первый, а strace — оба. Затем соберёте бинарник, в котором подменять нечего вообще. После этого перейдёте на другую сторону: посмотрите, что ядро знает о подсистеме BPF, прочитаете BTF-описание структур ядра и увидите, почему bpftrace без прав не запускается.

Работа состоит из семи частей и продвинутого задания. Части 1–4, 6 и 7 не требуют прав суперпользователя: все измерения выполняются на обычной учётной записи, а там, где нужен root, работа честно показывает отказ вместо падения. Часть 7 в среде без root заменяется эмуляцией через strace — и это не компромисс, а отдельный полезный навык: понимать, какие события ядро фиксирует, не имея доступа к загрузке программ.

Принцип каждой части один: предсказать — проверить — объяснить. Сначала запишите в журнал, что должно получиться и почему. Потом выполните команду. Потом объясните расхождение, если оно есть. Расхождение — не ошибка, а самая ценная часть работы.

Цель работы

Освоить механизм перехода в ядро на архитектуре x86_64 и научиться различать уровни, на которых операция становится видимой или невидимой для средств мониторинга.

После выполнения работы получится:

• находить номера системных вызовов и их сигнатуры в заголовочных файлах ядра;
• собирать LD_PRELOAD-перехватчик и объяснять, почему он работает не для всех программ;
• реализовывать прямой системный вызов через syscall() и через встроенный ассемблер, не путая R10 и RCX;
• собирать статический бинарник без libc и доказывать отсутствие зависимостей через readelf;
• объяснять, почему ltrace и strace дают разную картину одного и того же действия;
• снимать состояние подсистемы BPF и отличать «параметр скрыт» от «параметр равен нулю»;
• читать BTF-описание ядра и находить смещения полей task_struct без bpftool;
• локализовать и исправлять ошибку в номере системного вызова по коду возврата -EBADF;
• формулировать, что именно увидит защитник на каждом из уровней.

Теоретический минимум

Перед работой стоит перечитать в теме 08 разделы «Анатомия перехода: инструкция syscall и регистры», «Программа без libc: -nostdlib и собственная точка входа» и «Что администратор видит до всяких утилит». Ключевое, что понадобится:

• конвенция x86_64: номер вызова в RAX, аргументы в RDI, RSI, RDX, R10, R8, R9, результат в RAX как 0..N или -errno;
• инструкция syscall затирает RCX и R11, поэтому четвёртый аргумент идёт в R10;
• прямой вызов не выставляет errno: ошибка возвращается отрицательным числом;
• LD_PRELOAD работает только для динамически слинкованных программ, обращающихся к символу через PLT;
• eBPF загружается через bpf(BPF_PROG_LOAD, ...), проверяется верификатором и привязывается к событию;
• bpftrace и bpftool требуют CAP_BPF/CAP_SYS_ADMIN и доступа к tracefs.

Таблица команд и интерфейсов, которые используются в работе:

Перечень оснащения

• Linux x86_64 (проверялось на ядре 7.2.4-zen2-1-zen, подойдёт Ubuntu 24.04, Arch, Fedora);
• gcc, make, binutils (readelf, nm), strace, ltrace, python3;
• по желанию: bpftrace, bpftool, пакет libbpf — для части 7 на своей машине;
• архив материалов окружения lr-env.

Рабочий каталог — ~/lab-08/lr-env (именно в него распаковывается архив). Все команды ниже выполняются из него, если не сказано иное.

mkdir -p ~/lab-08 && cd ~/lab-08
unzip -q lr-env.zip          # распакуется в каталог lr-env/
cd lr-env
make
make check

собрано: build/cmp build/naked build/buggy_syscall build/shim.so
baseline.sh: синтаксис ок
mock_tracer.sh: синтаксис ок
btf_dump.py: синтаксис ок
btf_dump.py: запуск ок
проверка завершена

Если make check падает на btf_dump.py, значит ядро собрано без BTF (CONFIG_DEBUG_INFO_BTF). Это не ломает части 1–5; для части 6 достаточно записать в журнал, что BTF недоступен, и объяснить причину.

Полезно сразу зафиксировать среду:

./src/check_env.sh

ядро: 7.2.4-zen2-1-zen
архитектура: x86_64
gcc: есть
make: есть
strace: есть
ltrace: есть
bpftrace: есть
bpftool: НЕТ
readelf: есть
nm: есть
python3: есть
права: пользователь noviui — загрузка eBPF недоступна
BTF: доступен (6378085 байт)
tracefs: не читается без root — bpftrace не запустится
итог: части 1-4, 6-7 работают без root; часть 5 требует root

Обратите внимание: bpftrace в списке есть, а tracefs не читается. Установленный инструмент и доступный инструмент — разные вещи, и это первое наблюдение работы.

Порядок выполнения работы

Части идут от пользовательского уровня к ядерному. Не перескакивайте: часть 3 опирается на вывод части 2, а часть 7 — на снимок из части 6.

1. Часть 1 — таблица номеров и два пути к одному вызову.
2. Часть 2 — библиотечный перехватчик.
3. Часть 3 — прямой вызов через syscall() и ассемблер.
4. Часть 4 — бинарник без libc.
5. Часть 5 — поиск и исправление ошибки в номере вызова.
6. Часть 6 — снимок подсистемы BPF и чтение BTF.
7. Часть 7 — трейсер в ядре и его обнаружение.
8. Продвинутая часть — свой счётчик execve и разбор того, как его ловят.

Часть 1. Таблица номеров и два пути к одному вызову

Задание

1. Найдите номера нужных вызовов в заголовочном файле:

grep -E '__NR_(read|write|open|close|execve|bpf)\b' /usr/include/asm/unistd_64.h

#define __NR_read 0
#define __NR_write 1
#define __NR_open 2
#define __NR_close 3
#define __NR_execve 59
#define __NR_bpf 321

2. Обратите внимание на open и openat. На современных системах open (номер 2) почти не используется: программы вызывают openat (номер 257), потому что он умеет работать относительно дескриптора каталога. Проверьте:

grep -E '__NR_openat\b' /usr/include/asm/unistd_64.h

#define __NR_openat 257

3. Соберите программу build/cmp, которая читает из стандартного ввода двумя путями — через read() и через syscall(SYS_read, ...):

make build/cmp
printf 'ab\n' | ./build/cmp

3 0

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

4. Посмотрите на программу глазами библиотечного трассировщика:

printf 'ab\n' | ltrace -e 'read+syscall' ./build/cmp

cmp->read(0, "ab\n", 8)                          = 3
cmp->syscall(0, 0, 0x7ffd32fa2440, 8)            = 0

5. Посмотрите на неё же глазами ядерного трассировщика:

printf 'ab\n' | strace -e trace=read ./build/cmp

read(0, "ab\n", 8)                      = 3
read(0, "", 8)                          = 0

Что должно получиться

В журнале — три вывода и один абзац объяснения. Суть объяснения: ltrace показывает библиотечный read с именем и результатом, а syscall — как вызов с числом 0 в первом аргументе, потому что для ltrace это просто число, а не имя функции. strace показывает два одинаковых read(0, ...) и не различает пути вообще: для ядра путь безразличен, важен только номер в RAX.

Дополнительно запишите, чем отличаются два вывода по форме: ltrace печатает имя символа и его аргументы, strace — имя сисколла и результат. Это разные уровни абстракции, и дальше работа всё время будет ходить между ними.

Часть 2. Библиотечный перехватчик: что видит EDR

Задание

1. Изучите src/shim.c. Перехватчик подменяет read, получает настоящую функцию через dlsym(RTLD_NEXT, "read") и логирует только чтение с дескриптора 0:

ssize_t read(int fd, void *buf, size_t count)
{
    static ssize_t (*real_read)(int, void *, size_t) = NULL;

    if (!real_read)
        real_read = (ssize_t (*)(int, void *, size_t))dlsym(RTLD_NEXT, "read");
    if (!real_read)
        return -1;

    ssize_t n = real_read(fd, buf, count);
    if (fd == 0 && n > 0)
        fprintf(stderr, "[SHIM] fd=0 bytes=%zd data=\"%.*s\"\n",
                n, (int)(n > 32 ? 32 : n), (char *)buf);
    return n;
}

2. Соберите и примените его к cmp:

make build/shim.so
printf 'secret\n' | LD_PRELOAD=./build/shim.so ./build/cmp

[SHIM] fd=0 bytes=7 data="secret
"
7 0

3. Объясните, почему строка [SHIM] одна, а вызовов read было два. Ответ: перехватчик сработал на библиотечном вызове, а прямой вызов syscall() прошёл мимо него.

4. Проверьте, что перехватчик не мешает самой программе: результат 7 0 совпадает с тем, что было без LD_PRELOAD.

5. Убедитесь, что перехват не является «магией»: посмотрите, какие символы экспортирует shim.so и откуда берётся настоящий read:

nm -D build/shim.so | grep -E ' (T|U) '

                 U dlsym@GLIBC_2.34
                 U fprintf@GLIBC_2.2.5
0000000000001120 T read
                 U stderr@GLIBC_2.2.5

T read — перехватчик экспортирует собственный read, поэтому загрузчик подставляет его раньше библиотечного. U dlsym — сам он зависит от библиотеки, чтобы найти оригинал; суффикс @GLIBC_2.34 показывает версию символа, которую требует бинарник. Номера адресов у вас будут другими, буквы T/U — те же.

Что должно получиться

Зафиксировано: LD_PRELOAD-перехват видит ровно те вызовы, которые идут через библиотеку. Прямой вызов остаётся невидимым. В журнале — вывод с одной строкой [SHIM] и объяснение, почему вторая операция чтения не попала в лог.

Это модель user-mode EDR в миниатюре: агент видит всё, что делает библиотека, и ничего из того, что делает программа напрямую.

Часть 3. Прямой вызов: syscall() и ассемблер

Задание

1. Разберите функцию из src/cmp.c и напишите свою версию чтения через встроенный ассемблер. В окружении её нет — создайте файл asm_read.c:

#define _GNU_SOURCE
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

static long asm_read(int fd, void *buf, size_t count)
{
    long ret;
    __asm__ volatile (
        "movq $0, %%rax\n\t"        /* __NR_read = 0 */
        "movq %1, %%rdi\n\t"        /* arg1: fd */
        "movq %2, %%rsi\n\t"        /* arg2: buf */
        "movq %3, %%rdx\n\t"        /* arg3: count */
        "syscall\n\t"
        "movq %%rax, %0\n\t"
        : "=r"(ret)
        : "r"((long)fd), "r"(buf), "r"((long)count)
        : "rax", "rdi", "rsi", "rdx", "rcx", "r11", "memory"
    );
    return ret;
}

int main(void)
{
    char buf[64];
    long n = asm_read(0, buf, sizeof buf);
    if (n < 0) {
        fprintf(stderr, "ошибка: %ld\n", n);
        return 1;
    }
    printf("прочитано %ld байт\n", n);
    return 0;
}

2. Соберите и запустите под тем же перехватчиком:

gcc -O2 -Wall -Wextra -o build/asm_read asm_read.c
printf 'token\n' | LD_PRELOAD=./build/shim.so ./build/asm_read

прочитано 6 байт

Строки [SHIM] нет — и это ожидаемый результат.

3. Проверьте, что ядро операцию увидело:

printf 'token\n' | strace -e trace=read ./build/asm_read

read(0, "token\n", 64)                  = 6

4. Эксперимент с регистром. Замените в блоке %%rdx на %%rcx — то есть положите третий аргумент туда, где его никто не ждёт. Пересоберите и запустите. Программа не прочитает ничего осмысленного: count окажется случайным числом, а если он велик — чтение всё равно вернёт не больше, чем есть в буфере терминала. Запишите наблюдение и объясните: RCX затирается инструкцией syscall (в него процессор кладёт адрес возврата), поэтому третий аргумент в RCX невозможен, а четвёртый — возможен только в R10.

5. Эксперимент с ошибкой. Замените номер вызова на заведомо неверный — 9999:

printf 'token\n' | ./build/asm_read

ошибка: -38

-38 — это -ENOSYS, «функция не реализована». Обратите внимание: программа печатает именно отрицательное число, потому что прямой вызов не выставляет errno. Это отличие от библиотечного вызова, где ошибка видна через errno и -1, стоит запомнить: оно понадобится в части 5.

Что должно получиться

Собранный asm_read, работающий без libc-обёртки read. В журнале — три вывода: успешное чтение под LD_PRELOAD без строки [SHIM], подтверждение через strace и разбор двух экспериментов. Главный вывод части: прямой вызов меняет только то, кто вызвал ядро, но не то, что ядро увидело.

Часть 4. Бинарник без libc

Задание

1. Соберите build/naked — программу со своей точкой входа _start, без стандартной библиотеки:

make build/naked
./build/naked

naked binary: no libc, no hooks

2. Докажите, что зависимостей от разделяемых библиотек нет:

LC_ALL=C readelf -d build/naked | grep NEEDED || echo "нет зависимостей от .so"
LC_ALL=C readelf -h build/naked | grep 'Entry point'
ldd build/naked

нет зависимостей от .so
  Entry point address:               0x401000
	не является динамическим исполняемым файлом

Три вывода подтверждают одно и то же с разных сторон: таблица NEEDED пуста, точка входа задана явно, ldd отказывается считать файл динамическим.

3. Примените перехватчик к статическому бинарнику:

LD_PRELOAD=./build/shim.so ./build/naked

naked binary: no libc, no hooks

Строки [SHIM] нет. Сравните с частью 2, где она была. Разница не в «защите», а в отсутствии точки подмены.

4. Предсказание. До запуска запишите: сработает ли strace на статическом бинарнике? Проверьте:

strace -e trace=write,exit ./build/naked

write(1, "naked binary: no libc, no hooks\n", 32) = 32
exit(0)                                 = ?
+++ exited with 0 +++

strace работает: он не зависит от библиотек, потому что трассирует сам переход в ядро через ptrace.

5. Посмотрите размер и таблицу символов:

stat -c '%s байт' build/naked
nm build/naked | head -5

Запишите размер. Он измеряется килобайтами, а не сотнями килобайт, именно потому, что в файле нет ни libc, ни её инициализации.

Что должно получиться

В журнале — доказательство отсутствия зависимостей и сравнение двух запусков с LD_PRELOAD: на cmp перехват срабатывает, на naked — нет. Вывод для защиты: белые списки по хешу и контроль целостности работают против статических бинарников лучше, чем библиотечные хуки, потому что хукам там не за что зацепиться.

Часть 5. Найти и исправить ошибку в номере вызова

Задание

1. Соберите программу с намеренной ошибкой:

gcc -O2 -Wall -Wextra -o build/buggy_syscall src/buggy_syscall.c
echo test | ./build/buggy_syscall

Попытка чтения ввода через прямой syscall...
Ошибка syscall: код возврата -9 (это -EBADF, errno=0)

2. Разберите код возврата. -9 — это -EBADF, «некорректный файловый дескриптор». Вопрос: почему чтение с дескриптора 0 даёт ошибку «некорректный дескриптор», если stdin заведомо открыт?

3. Найдите причину в исходнике. Подсказка: посмотрите на первый аргумент вызова и на константы __NR_read/__NR_write из части 1.

4. Исправьте ошибку: в вызове raw_syscall3(1, 0, (long)buf, sizeof buf) номер 1 — это __NR_write. Замените его на 0. Пересоберите и проверьте:

echo "исправлено" | ./build/buggy_syscall

Попытка чтения ввода через прямой syscall...
Успешно прочитано байт: 21

5. Объясните, почему ошибка выглядела именно так. write(0, buf, 128) пытается писать в дескриптор, открытый только на чтение; ядро отказывает с EBADF. Если бы номер был, скажем, 60 (exit), программа завершилась бы молча и без вывода — и это была бы куда более неприятная ошибка, потому что её не видно.

6. Дополнительно. Проверьте, что происходит с errno после прямого вызова:

errno = 0;
long n = raw_syscall3(1, 0, (long)buf, sizeof buf);
printf("n=%ld errno=%d\n", n, errno);

Убедитесь, что errno остался нулём: прямой вызов не трогает errno, он возвращает -errno в RAX. Отсюда правило: после прямого вызова проверяют знак результата, а не errno.

Что должно получиться

Исправленный buggy_syscall, читающий ввод. В журнале — исходный вывод с -9, объяснение связи между номером вызова и EBADF, и вывод после исправления. Дополнительно — вывод с errno=0, доказывающий, что прямой вызов не выставляет errno.

Часть 6. Снимок подсистемы BPF и чтение BTF

Задание

1. Снимите состояние подсистемы:

./src/baseline.sh > before.txt
cat before.txt

=== снимок 2026-10-19T18:40:35+03:00 ===
ядро = 7.2.4-zen2-1-zen
unprivileged_bpf_disabled = 2
bpf_jit_enable = 1
bpf_jit_harden = НЕТ ДОСТУПА
perf_event_paranoid = 2
lockdown = [none] integrity confidentiality
btf_vmlinux_байт = 6378085
bpf_prog_символов = 471
--- /sys/fs/bpf ---
НЕТ ДОСТУПА
--- bpftool ---
не установлен

2. Разберите каждую строку. Особое внимание на две:

• bpf_jit_harden = НЕТ ДОСТУПА — параметр существует, но имеет права 0600, и непривилегированный процесс получает отказ. Проверьте:

ls -l /proc/sys/net/core/bpf_jit_harden

-rw------- 1 root root 0 окт 19 18:40 /proc/sys/net/core/bpf_jit_harden

• bpf_prog_символов = 471 — это не «471 шпион», а все программы подсистем, включая встроенные. Само по себе число бесполезно; полезен дифф двух снимков.

3. Сделайте второй снимок и сравните:

./src/baseline.sh > after.txt
diff before.txt after.txt

Если между снимками ничего не загружалось, diff пуст — и это правильный baseline. Любая строка в диффе, кроме времени, — повод разбираться.

4. Прочитайте BTF-описание ядра. Сначала посмотрите на заголовок файла:

./src/btf_dump.py

файл BTF: 6378085 байт, типов: 143964
struct task_struct: id=131625 size=6144 байт, полей=268
  tasks        смещение  2664 байт (0xa68)
  mm           смещение  2744 байт (0xab8)
  pid          смещение  2872 байт (0xb38)
  tgid         смещение  2876 байт (0xb3c)
  parent       смещение  2896 байт (0xb50)
  real_cred    смещение  3384 байт (0xd38)
  cred         смещение  3392 байт (0xd40)
  comm         смещение  3408 байт (0xd50)

5. Задайте другую структуру и другие поля — скрипт принимает их аргументами:

./src/btf_dump.py cred uid gid euid

Запишите результат: это те самые поля, через которые в теме 04 перезаписывается личность процесса. Обратите внимание, что скрипт не требует bpftool, не требует root и не загружает никаких программ: он просто читает файл, который ядро отдаёт всем.

6. Ответьте на вопрос: почему смещение cred (0xd40) не является константой, на которую можно закладываться в программе? Проверьте размер task_struct: он меняется от версии к версии и от конфигурации ядра. Именно поэтому существует CO-RE.

Что должно получиться

Два снимка состояния и разобранный вывод btf_dump.py. В журнале — объяснение разницы между «параметр скрыт» и «параметр равен нулю», и вывод о том, что BTF даёт смещения полей без единой привилегии.

Часть 7. Трейсер в ядре и его обнаружение

Задание

1. Изучите src/read_sniffer.bt. Скрипт подключается к двум точкам: на входе запоминает адрес буфера, на выходе читает прочитанные байты. Обратите внимание на условие /args->fd == 0/ — оно отсекает всё, кроме стандартного ввода.

2. Если у вас есть root, запустите трассировщик в одном терминале:

sudo bpftrace src/read_sniffer.bt

а в другом — программу, читающую stdin:

printf 'demo\n' | ./build/cmp

3. Если root нет, зафиксируйте отказ и объясните его:

bpftrace -e 'tracepoint:syscalls:sys_enter_read { printf("x\n"); }'

ERROR: Missing CAP_DAC_READ_SEARCH capability, please run bpftrace as the root user.

Это не ошибка установки. bpftrace нужен доступ к tracefs и право загрузить программу; без CAP_BPF/CAP_SYS_ADMIN он честно отказывается.

4. Замените трассировщик эмуляцией — она показывает те же два события, но через strace:

./src/mock_tracer.sh ./build/cmp

=== события sys_read для ./build/cmp (эмуляция двух точек трассировки) ===
[sys_enter_read] pid=7 fd=0 (буфер ещё пуст)
[sys_exit_read]  pid=7 прочитано байт: 8
[sys_enter_read] pid=7 fd=0 (буфер ещё пуст)
[sys_exit_read]  pid=7 прочитано байт: 2

5. Объясните, почему в паре «вход/выход» на входе буфер ещё пуст. В точке sys_enter_read ядро только собирается выполнить чтение; данные появятся к моменту sys_exit_read. Именно поэтому bpftrace-сниффер обязан запомнить адрес буфера на входе и прочитать его на выходе — это и есть смысл двух карт в скрипте.

6. Обнаружение. Посмотрите, что остаётся в системе после работы трассировщика (в среде с root):

sudo bpftool prog show
sudo bpftool link show
ls -la /sys/fs/bpf

Запишите в журнал: тип программы, её имя, тег, map_ids, наличие закреплённых объектов. Затем ответьте на вопрос: что из этого останется после завершения bpftrace, а что исчезнет вместе с процессом?

Что должно получиться

Понимание разницы между двумя точками перехвата и того, почему сниффер без второй точки бесполезен. В журнале — либо реальный вывод bpftrace, либо отказ с объяснением и вывод mock_tracer.sh. Обязательно — разбор того, какие следы остаются в подсистеме BPF и почему bpftool prog show видит программу, которую не видит ни один процесс.

Продвинутая часть. Свой счётчик execve и его обнаружение

Задание необязательное. Выполняется на машине с root и bpftrace.

1. Напишите скрипт, который считает вызовы execve по имени процесса:

tracepoint:syscalls:sys_enter_execve
{
    @calls[comm] = count();
}

interval:s:5
{
    print(@calls);
    clear(@calls);
}

2. Запустите его и в течение десяти секунд поработайте в другом терминале: несколько раз вызовите ls, cat, grep.

3. Разберите вывод: какие процессы запускаются чаще всего и почему. Обратите внимание, что bash тоже вызывает execve — при каждом запуске внешней команды.

4. Обнаружение. Ответьте письменно:

• что покажет bpftool prog show про эту программу (тип, имя, тег);
• что покажет bpftool map show про карту @calls;
• останется ли программа после Ctrl+C и почему;
• какое правило auditd поймает загрузку этой программы:

sudo auditctl -a always,exit -F arch=b64 -S bpf -k bpf_load
sudo ausearch -k bpf_load -i | tail -20

5. Сформулируйте, чем отличается обнаружение «по процессу» от обнаружения «по подсистеме». Первое ищет подозрительный бинарник и проигрывает, потому что бинарник выглядит обычным. Второе смотрит на список программ, ссылок и закреплённых объектов и находит сам факт присутствия в ядре.

Журнал работы

Журнал ведётся по частям. Для каждой части фиксируются: предсказание, команда, фактический вывод, объяснение расхождения. Обязательный минимум:

В конце журнала — сводная таблица «уровень — что видит — что не видит»:

Заполните её своими результатами, а не переписывайте: если в вашей среде какая-то ячейка ведёт себя иначе, это самое интересное место журнала.

Контрольные вопросы

1. Почему четвёртый аргумент системного вызова передаётся в R10, а не в RCX? Что именно процессор делает с RCX при выполнении syscall?
2. Чем отличается результат прямого вызова при ошибке от результата библиотечной обёртки? Как в каждом случае узнают причину?
3. Почему ltrace показывает syscall как вызов с числом, а strace — как полноценный read? На каком уровне работает каждый инструмент?
4. Что означает пустая таблица NEEDED в readelf -d и почему после этого LD_PRELOAD не действует?
5. Почему статический бинарник без libc всё равно виден strace, хотя в нём нет ни одной библиотечной функции?
6. Как отличить «параметр ядра скрыт от процесса» от «параметр равен нулю»? Приведите пример из части 6.
7. Почему bpf_prog_символов = 471 само по себе ничего не доказывает и какой приём делает это число полезным?
8. Зачем снифферу read нужны две точки перехвата, а не одна? Что произойдёт, если читать буфер в sys_enter_read?
9. Что такое BTF и почему смещение поля cred нельзя зашивать в программу константой?
10. Какие права нужны bpftrace и почему установленный инструмент может быть непригоден в конкретной среде?
11. Чем отличается обнаружение «по процессу» от обнаружения «по подсистеме»? Какое из них надёжнее и почему?
12. Что останется в системе после завершения bpftrace, а что исчезнет вместе с процессом? Как это связано с BPF_LINK_CREATE и закреплением в /sys/fs/bpf?
13. Почему прямой системный вызов обходит LD_PRELOAD, но не обходит seccomp? Где именно срабатывает каждый механизм?
14. Какое правило auditd фиксирует загрузку программ eBPF и почему в его выводе будут и легитимные записи?

Уборка

После работы удалите собранное и временные файлы:

./src/cleanup.sh

каталог работы: /home/user/lab-08/lr-env
удалено: build/, before.txt, after.txt, diff.txt, __pycache__, временные файлы
исходники в src/ сохранены

Если вы запускали bpftrace или auditd-правило, снимите за собой:

sudo pkill bpftrace
sudo auditctl -W arch=b64 -S bpf -k bpf_load
sudo auditctl -l

Проверьте, что закреплённых объектов не осталось:

sudo ls -la /sys/fs/bpf

Каталог должен быть пуст, кроме . и ... Если в нём остались объекты от ваших экспериментов, удалите их по имени:

sudo rm -f /sys/fs/bpf/имя_объекта

Рабочий каталог ~/lab-08 можно удалить целиком: в нём нет ничего, что нужно сохранять, кроме вашего журнала.