Настройка и мониторинг файловой системы с использованием eBPF‑программ в Termux

eBPF (extended Berkeley Packet Filter) — это механизм динамического наблюдения за поведением системы без постоянного изменения ядра. При грамотной настройке eBPF‑программы позволяют анализировать события уровня ядра: сетевые потоки, планирование процессов и, что особенно важно для администрирования, действия с файловой системой (open, read, write, unlink и т.п.).

В этом материале мы разберём, как организовать мониторинг файловой системы с использованием eBPF в Termux в условиях Android и Linux‑совместимой среды, а также обсудим реальные ограничения, которые встречаются на практике. Материал ориентирован на легальные и безопасные сценарии диагностики, аудита и отладки.

Ключевые ограничения Android/Termux при использовании eBPF

Хотя Termux предоставляет удобный интерфейс командной строки и компиляторные возможности, eBPF упирается в возможности ядра Android и его настройки. На практике вы почти всегда столкнётесь с одним из вариантов:

Ограниченный доступ к eBPF: ядро может быть скомпилировано без нужных опций (CONFIG_BPF, CONFIG_BPF_JIT, и т.д.).
Запрет BPF‑системных вызовов в обычном режиме безопасности: даже если сборка инструментов проходит, загрузка программ может завершаться ошибками.
Разный набор трассируемых точек: доступность kprobes/tracepoints зависит от версии ядра и конфигурации.
Права: для некоторых операций нужны повышенные привилегии или особенности sandbox’а.

Поэтому правильный подход — начинать с проверки возможностей и только затем переходить к сборке/загрузке eBPF‑программ.

Подготовка окружения в Termux

Начните с базовой подготовки. Установите необходимые пакеты, чтобы иметь возможность компилировать eBPF‑компоненты, читать логи и работать с инструментами ядра.

pkg update && pkg upgrade -y
pkg install -y clang llvm tar git make cmake python rsync util-linux coreutils bison flex

Далее установим пользовательские утилиты для диагностики. Набор может отличаться в зависимости от версии Termux.

pkg install -y strace procps lsof

Если вы планируете собирать инструменты eBPF из исходников, потребуются дополнительные компоненты для build‑цепочки. На практике часто удобнее начинать с готовых репозиториев eBPF‑утилит (например, семейства uBPF/bcc/libbpf‑проектов) и адаптировать под Android.

Проверка поддержки eBPF в ядре

Важнейший шаг — убедиться, что ядро поддерживает загрузку eBPF‑программ и есть возможность получать события. В Termux вы можете начать с общих признаков:

Проверка версии ядра.
Поиск интерфейсов для BPF (например, файлов в /sys/fs/bpf).
Проверка наличия bpftool или аналогов.

Попробуйте узнать версию ядра:

uname -a

Проверьте, смонтирован ли BPF filesystem:

ls -la /sys/fs/bpf 2>/dev/null || echo "No /sys/fs/bpf"

Если файловая система доступна, можно попытаться создать точку монтирования (на некоторых устройствах она уже смонтирована):

mount | grep bpf || true

Далее — попробуйте установить bpftool или любой инструмент проверки. Если пакет недоступен, используйте сборку из исходников или используйте минимальные тесты через eBPF‑SDK, который вы выберете. Важно: успешная сборка утилит не гарантирует, что ядро даст загрузить программу.

Концепция мониторинга файловой системы через eBPF

Для мониторинга файловой системы eBPF обычно использует один из подходов:

Tracepoints/kprobes на путях работы VFS (Virtual File System) ядра.
LSM‑hooks (в зависимости от конфигурации ядра) для перехвата операций безопасности.
Сбор статистики через BPF maps: счетчики по PID/путям, агрегирование латентности (в пределах возможностей).

В сценарии «аудит файловой активности приложения в Termux» чаще всего интересуют события уровня ядра:

Открытие файла (open/openat)
Чтение (read) и запись (write)
Удаление (unlink)
Переименование (rename)

Реализовать это можно как напрямую (на уровне C‑кода eBPF и компиляции через clang), так и через готовые инструменты (которые трассируют события и выводят события в формате, удобном для анализа).

Безопасная схема: сначала наблюдение, потом углубление

На Android особенно важно начинать с «мягких» режимов:

Сначала проверьте, что вы получаете любые события eBPF (например, по процессам вашего пользователя).
Затем ограничьте фильтры: PID вашего Termux‑шелла, конкретные директории (например, /data/data/<package> или ваша рабочая директория Termux).
И только потом наращивайте функциональность (например, собирайте точные пути, агрегируйте статистику, добавляйте корреляцию по PID и TID).

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

Пример: идея eBPF‑наблюдения за openat

Ниже показан концептуальный пример того, как обычно выглядит eBPF‑программа: перехват события openat, фильтрация по PID и передача данных в user space через map/perf buffer. В реальных условиях конкретные attach‑точки зависят от версии ядра и доступности BTF/tracepoints.

Сама компиляция и подцепление на Android может отличаться. Рассматривайте пример как структурный ориентир: правильные секции, attach‑hooks и мапы необходимо подбирать под вашу среду.

// Концептуальный скелет eBPF (адаптация под ваше ядро обязательна)
#include <linux/ptrace.h>
#include <bpf/bpf_helpers.h>

struct event {
  u32 pid;
  char filename[256];
};

struct {
  __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
} events SEC(".maps");

SEC("tracepoint/syscalls/sys_enter_openat")
int on_openat(struct trace_event_raw_sys_enter *ctx) {
  // Дальше обычно извлекают pid и filename (или pathname) из аргументов syscalls
  // Затем отправляют событие в user space.
  return 0;
}

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

Если трасс‑точки в вашем ядре недоступны, потребуется заменить attach‑точку на подходящую kprobe/tracepoint или LSM‑hook. Поэтому практический путь — начинать с перечисления доступных событий (если доступно) и тестировать attach.

Сбор и запуск: практический план

Ниже — типовой план работ, который можно повторить в Termux. Он предполагает, что у вас есть возможность компилировать и грузить eBPF (или хотя бы диагностировать почему нельзя).

Соберите eBPF‑объект с помощью clang.
Проверьте загружается ли программа и открывается ли канал для событий (perf buffer/ring buffer).
В user space выведите события и проверьте корректность полей (PID, путь, коды ошибок).
Добавьте фильтрацию по PID/UID и директорий для снижения шума.

Пример команд для сборки будет выглядеть примерно так (зависит от структуры проекта и используемых заголовков):

# Пример сборки eBPF object (команды могут отличаться под ваш проект)
clang -O2 -g -target bpf -c ebpf_program.c -o ebpf_program.o

Дальше обычно нужен loader (часть user space), который загружает .o и подключает attach‑точки. Для этого часто используют libbpf или готовые утилиты/скрипты.

Мониторинг конкретной директории Termux

Чтобы наблюдение не превращалось в «шумный» поток, практично ограничить область интереса. Например, если вы хотите отслеживать файловые операции в каталоге Termux, начните с вашей рабочей директории (она обычно находится в домашней области, которая в Termux соответствует текущему пользователю).

Сначала определите текущий путь:

pwd

Затем в eBPF‑логике (или в user‑space после получения события) примените фильтр на префикс пути. На практике фильтрация на стороне eBPF возможна, но потребует аккуратной работы с памятью строк и лимитами размера (например, 256 байт или иной буфер).

Если eBPF возвращает только часть строки или номер/индикатор, можно:

Коррелировать по PID и затем в user space восстанавливать контекст.
Оставить сбор «коротких» метаданных (PID, syscall id, inode номер, если доступно) и уже в user space разворачивать детали.

Использование eBPF для аудита и отладки (а не «обхода»)

Юридически и технически корректный сценарий — диагностика того, кто и что делает с файлами: аудит активности, поиск источника нежелательных обращений к файлам, оценка влияния компонентов на файловую подсистему.

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

Типичные ошибки и как их диагностировать

«Permission denied» при загрузке: проверьте права, доступность /sys/fs/bpf, статус SELinux (на Android часто много ограничений). Иногда требуется альтернативный путь (например, через другой контекст/устройство с поддержкой).
«No such tracepoint»: ядро не содержит нужной tracepoint/trace config. Нужно подобрать attach‑точку под вашу версию.
Пустой поток событий: фильтр слишком строгий (не тот PID/путь), либо буфер не отправляет данные, либо attach не сработал.
Перегруз по событиям: добавьте rate limiting или используйте агрегацию (счетчики), а не печать каждого события.

Интеграция с локальной сетью (при необходимости)

Если вам нужно передавать результаты мониторинга на другой хост для визуализации, в рамках законного администрирования допустим сценарий создания локальной сети между устройствами (например, через VPN для организации частного канала без обхода блокировок). Конкретная реализация зависит от ваших средств и политики компании/проекта.

При этом помните: eBPF сам по себе не требует сети; сеть нужна только для доставки агрегированных результатов (например, метрик или логов) в систему наблюдения.

Заключение

Мониторинг файловой системы с использованием eBPF в Termux — мощный подход для аудита, диагностики и отладки, но он напрямую зависит от возможностей ядра Android и доступных attach‑точек. Правильная стратегия начинается с проверки поддержки eBPF, затем — с минимального набора событий и мягких фильтров, и только потом выстраивается более подробная трассировка (open/read/write/unlink/rename) с контролем нагрузки и корректной корреляцией по PID.

Если вы хотите быстрее получить рабочее решение под ваше устройство/ядро и настроить наблюдение «под ключ» (включая подбор attach‑точек, оптимизацию фильтров и вывод в удобный формат), обращайтесь в РыбинскЛАБ. Мы поможем спроектировать и внедрить мониторинг eBPF в вашем Termux‑контуре с фокусом на надежность и соответствие требованиям.