Использование ptrace и seccomp‑фильтров для реализации пользовательского песочника

Termux часто используют как удобную оболочку и платформу для разработки/обкатки утилит в среде Android. Однако даже при наличии ограничений ОС остаются риски: выполнение вредоносного кода, неконтролируемые системные вызовы, попытки обращения к файлам или сети. Один из подходов к снижению риска — реализовать «песочницу» на уровне ядра: ограничивать процесс и его взаимодействие с системой.

В этом материале рассматривается безопасный, прикладной взгляд на использование ptrace и seccomp‑фильтров для контроля поведения процесса. Фокус — на архитектуре, принципах и практических ограничениях в пользовательских сценариях Termux под Linux-совместимыми ядрами Android.

Ключевая идея: разделение контроля на уровни

Песочник обычно строят как комбинацию нескольких слоёв контроля:

• Контроль системных вызовов — через seccomp: ядро может разрешать или запрещать конкретные syscalls.
• Наблюдение и управление выполнением — через ptrace: отладчик/трейсер может останавливать процесс, читать регистры, перехватывать моменты выполнения.
• Ограничение доступа к ресурсам — через стандартные механизмы ОС (например, namespaces/cgroups), если они доступны.

При этом важно понимать: реализация полной песочницы требует привилегий/возможностей, которые в обычном Termux-режиме могут быть ограничены. Поэтому разумная стратегия — делать частичный песочник и использовать максимально допустимые механизмы.

ptrace: роль трассировки процесса

ptrace — это интерфейс, позволяющий одному процессу наблюдать и управлять другим процессом (обычно через режимы остановки/продолжения и считывание состояния). В песочнике ptrace чаще применяют как:

• механизм «раннего торможения» — остановить процесс на событиях и проверить контекст;
• контроль некоторых побочных действий — например, отследить последовательность syscalls (хотя для строгого запрета seccomp обычно лучше);
• добавление логирования/аудита: трассирующий процесс собирает события и решения принимает на основе политики.

В Linux-практике ptrace требует, чтобы трассируемый процесс мог быть присоединён (это определяется политиками ядра и настройками; на Android часто действуют ограничения). Также следует учитывать, что ptrace может быть вычислительно затратным: процесс будет часто останавливаться.

seccomp‑фильтры: строгий контракт на syscalls

seccomp позволяет приложению ограничить, какие системные вызовы оно может выполнять. На практике это часто реализуют через:

• seccomp-bpf (фильтры на основе правил),
• или более высокоуровневые библиотеки/обёртки в пользовательском пространстве.

Смысл для песочника: даже если процесс пытается обратиться к нежелательным syscalls (например, для чтения чувствительных данных или запуска опасных операций), ядро блокирует вызов.

На уровне безопасности важно правильно проектировать политику: «запретить всё, разрешить нужное» (deny-by-default) — идеальная модель, но в реальности её сложно сделать для произвольных приложений. Для песочника Termux обычно начинают с более узких профилей под конкретные типы задач (например, запуск локального утилитарного бинарника с ограничениями по сети и файловой системе).

Архитектура пользовательского песочника: разумный минимальный дизайн

Ниже — концептуальная схема, которую можно адаптировать под доступные возможности окружения:

• Контроллер (tracer/controller): процесс, который запускает целевой процесс и (если возможно) подключается через ptrace.
• Профиль seccomp: правила разрешения syscalls, загруженные в целевой процесс (идеально — до выполнения потенциально опасного кода).
• Белые списки ресурсов: ограничение разрешённых директорий/операций на уровне приложения и (по возможности) ОС.
• Наблюдение и аудит: логи событий, причины блокировок, статистика.

В практических проектах нередко seccomp используют как основной механизм, а ptrace — как дополнительный слой наблюдения и «умного контроля» (например, для диагностических сценариев или для настройки параметров до выполнения).

Ограничения в Termux и Android: что нужно учитывать

• Доступность ptrace/seccomp: зависит от ядра, сборки Android, политик безопасности и прав пользователя. В некоторых конфигурациях ptrace может быть ограничен.
• Непредсказуемость среды: библиотеки, системные интерфейсы и набор syscalls могут отличаться от «чистого» десктоп Linux.
• Производительность: ptrace добавляет накладные расходы на остановки/продолжения.
• Сложность универсального профилирования: «один профиль на всё» почти всегда ломается. Правильнее делать профили под категории приложений.

Поэтому в контексте Termux разумно строить песочник итеративно: сначала профилируете реальные syscalls допустимого приложения, затем формируете правила seccomp и добавляете наблюдение через ptrace там, где это оправдано.

Практика: подготовка окружения и подход к разработке профиля seccomp

Ниже приведён общий безопасный план разработки. Он не содержит инструкций по обходу ограничений — только методику формирования профиля.

1. Выберите конкретный целевой бинарник/скрипт и сценарий использования (например, «утилита должна читать только заданную директорию и не использовать запрещённые syscalls»).
2. Соберите набор наблюдаемых системных вызовов в тестовом режиме (инструменты мониторинга могут быть доступны в среде).
3. Сформируйте минимально необходимый allow-list syscalls.
4. Проверьте поведение на типичных входных данных и пограничных случаях.
5. Добавьте ptrace‑наблюдение для логирования событий и контроля контекста (только там, где это нужно).

Важно: запрет syscalls без учёта реальных потребностей приложения приводит к падениям. Поэтому итерации неизбежны.

Концептуальные примеры: как это выглядит в коде (в общих чертах)

Реализация seccomp обычно требует C/C++ и системных интерфейсов. Ниже — псевдо‑пример структуры (без «универсального чит-кода» под вашу среду). Идея — загрузить seccomp до запуска опасной части кода.

/ Псевдокод: подготовка профиля и установка seccomp в целевом процессе /
int main() {
    / 1) Создать/загрузить seccomp policy (allowlist) /
    / 2) Установить режим seccomp для текущего процесса /
    / 3) Запустить/продолжить выполнение целевого кода /
    return run_target();
}

Для ptrace контроллер обычно делает форк, запускает дочерний процесс и затем управляет остановками/событиями. Однако точный код зависит от конкретной стратегии (TRACEME/attach, обработка waitpid, фильтрация событий).

/ Псевдокод: каркас трассировщика /
pid_t pid = fork();
if (pid == 0) {
    / дочерний: подготавливаемся к трассировке, затем exec /
    // ptrace(TRACEME, 0, NULL, NULL);
    execve(target, argv, envp);
} else {
    / родитель: цикл обработки событий /
    while (wait_for_event(pid)) {
        / прочитать регистры/контекст (при необходимости) /
        / принять решение (логировать/разрешить/остановить) /
        // ptrace(PTRACE_CONT, pid, NULL, NULL);
    }
}

Если вам нужен рабочий прототип — корректный путь начинается с определения того, какие syscalls фактически нужны вашему процессу и какие события ptrace доступны в вашей сборке ядра.

Локальная сеть и песочники: важное уточнение

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

Политики безопасности: как формировать правила, чтобы не «сломать всё»

• Детализируйте цели: что процессу можно делать (файлы, вывод, разрешённые директории, сетевые операции).
• Используйте deny-by-default: лучше начать с узкого allow-list и расширять после тестов.
• Учитывайте динамические зависимости: загрузка библиотек, работа с динамическими линкерами, обращения к /proc и т.п.
• Сохраняйте трассировку для диагностики: ptrace/логи помогут понять, почему приложение не стартует после ужесточения seccomp.
• Тестируйте разные сценарии: не только «обычный кейс», но и ошибки ввода, пустые файлы, большие объёмы данных.

Типовые ошибки при внедрении ptrace/seccomp

• Слишком жёсткий профиль: приложение падает из-за запрещённого syscall, который вы не учли.
• Неправильная последовательность установки seccomp: если секьюрный профиль активировать поздно, часть нежелательных операций может успеть выполниться.
• Неверные ожидания по доступности ptrace: в некоторых конфигурациях ptrace может не присоединиться к процессу.
• Отсутствие логирования: без диагностик сложно понять, какой именно syscall заблокирован и какому действию он соответствует.

Заключение

Использование ptrace и seccomp‑фильтров — практичный путь к усилению изоляции в пользовательском песочнике. seccomp задаёт строгий контракт на системные вызовы, а ptrace помогает в наблюдении, аудите и диагностике, когда нужно понять поведение целевого процесса. В Termux и Android важно учитывать ограничения доступности и производительности, поэтому подход лучше строить итеративно: профилирование → формирование allow-list → проверка → добавление наблюдения.

Если вы планируете внедрить такой песочник в свой проект, подготовить профили seccomp под конкретные сценарии или оценить применимость ptrace в вашей среде, команда РыбинскЛАБ поможет с аудитом, прототипированием и эксплуатационной настройкой решений.