Глубокий аудит безопасности: построение и интеграция собственного профиля AppArmor для приложений Termux

Termux в типовой конфигурации работает как обычное Linux-приложение в пользовательском контексте. При этом на практике он может выступать «универсальным инструментом» для запуска команд, установки пакетов и работы с файлами. Отсюда ключевая проблема: даже при аккуратном использовании остаётся риск нежелательных действий из-за компрометации среды (например, уязвимые зависимости, вредоносные скрипты, неверно настроенные разрешения, ошибки оператора).

AppArmor полезен тем, что позволяет ограничить приложение политикой мандатного контроля доступа: что именно оно может читать/писать, какие пути файлов доступны, какие операции с сетью разрешены, и какие ресурсы/возможности ему недоступны. В результате вы получаете контролируемую поверхность, согласованную с вашим сценарием использования Termux.

Цели глубокого аудита безопасности

Прежде чем писать профиль AppArmor, важно пройти этап аудита. Хороший подход — исходить из принципа минимально необходимых привилегий (least privilege) и сформировать список допустимых действий Termux в вашей системе.

Сценарии использования: какие команды и инструменты вы реально запускаете в Termux (например, компиляция, работа с репозиториями, доступ к файлам внутри определённых директорий, использование конкретных сетевых протоколов).
Ресурсы и пути: какие директории Termux должен читать/писать (например, домашний каталог пользователя, внутреннее хранилище в вашей схеме монтирования, каталоги для пакетов и кэшей).
Сеть: какие типы сетевых соединений нужны (обычно — исходящие соединения для обновлений пакетов/доступа к репозиториям). При необходимости ограничьте адреса/порты.
Системные вызовы и поведение: какие операции приложению необходимы (например, выполнение бинарников, создание временных файлов, работа с tty/псевдо-терминалами).
Условия компрометации: что произойдёт при запуске вредоносного скрипта внутри Termux, и какие ограничения должны «погасить» последствия.

На этом шаге полезно зафиксировать базовую модель: что для вас считается «нормальным» поведением, а что — нежелательным.

Предварительные условия и ограничения

AppArmor работает в Linux с включённым LSM и наличием загруженного механизма AppArmor. В большинстве обычных серверов/ПК это доступно, однако на некоторых окружениях (особенно в мобильных/контейнерных стэках) может потребоваться специфическая поддержка ядра и режима загрузки профилей.

Также важно понимать: профиль AppArmor жёстко влияет на доступ к ресурсам. Ошибки в политике часто приводят к отказам в доступе (denied), что потребует итерационного уточнения профиля.

Шаг 1. Подготовка данных аудита

Чтобы профиль был не «в теории», а соответствовал реальности, соберите наблюдения за тем, что Termux делает в рабочем режиме.

Рекомендуемый процесс:

Запустите Termux и выполните типичный набор действий: обновления, запуск ваших основных утилит, работу с файлами, взаимодействие с репозиториями (если это часть сценария).
Соберите журнал отказов AppArmor (если он уже включён) либо используйте инструменты наблюдения, доступные в вашей системе.
Снимите список реально используемых путей: директории в домашнем каталоге, временные каталоги, кэш, рабочие директории, точки монтирования (в вашей системе Termux может видеть специфические каталоги).

На основе этих данных вы будете конструировать профиль: сначала «широко», затем постепенно ужесточать.

Шаг 2. Определение целевого объекта профилирования

AppArmor профилирует процессы по имени исполняемого файла или по привязкам к программе. В случае Termux вам нужно определить, какой бинарник должен быть ограничен политикой.

Практический подход:

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

Для простоты часто начинают с профиля для основного процесса (shell/launcher), а затем выделяют отдельные профили, если нужно тонкое управление.

Шаг 3. Базовый профиль AppArmor: минимально рабочая структура

Создадим «скелет» профиля, который затем будем уточнять. На практике пути и имя профиля должны соответствовать вашей системе.

Пример каркаса (адаптируйте под вашу среду):

# /etc/apparmor.d/local/usr.bin.termux-sandbox (пример)
# Название файла и директория могут отличаться в зависимости от дистрибутива

#include <tunables/global>

# ПРИМЕЧАНИЕ: замените путь и имя профиля на реальные.
profile usr.bin.termux-base flags=(attach_disconnected) {

  # Базовые возможности: start simple, tighten later.
  # Обычно безопаснее ограничивать способности постепенно.
  capability sys_chroot,        # при необходимости; иначе уберите
  capability setuid,           # обычно не нужно; проверьте фактическую потребность

  # Разрешаем выполнение обычных бинарников.
  # Подстройте под ваш rootfs/FS.
  /bin/ mr,
  /usr/bin/ mr,
  /usr/sbin/ mr,

  # Домашние данные и рабочие каталоги.
  # Это ключевой участок: задайте только то, что действительно нужно.
  @{HOME}/ rwk,

  # Публичные точки монтирования/каталоги, которые Termux должен видеть:
  # Подставьте ваши реально используемые пути.
  /sdcard/ rwk,
  /storage/ rwk,

  # Временные и кэш-данные
  /tmp/ rwk,
  @{PROC}/ r,
  @{SYS}/ r,

  # Выполнение сценариев из вашего рабочегo каталога
  # (если вы запускаете shell-скрипты, это часто нужно).
  @{HOME}/.local/bin/ mrwix,
  @{HOME}/ mrwix,

  # Терминал/tty может требовать осторожного разрешения.
  /dev/pts/ rw,
  /dev/null rw,
  /dev/random r,
  /dev/urandom r,

  # Сеть:
  # Если вы хотите начать с контролируемого минимума — сначала ограничьте,
  # затем расширяйте по результатам аудита.
  network inet stream,
  network inet6 stream,
}

Смысл этого шага: получить профиль, который в принципе запускает ваши сценарии, но уже уменьшает доступ к файловой системе. Далее вы переходите к итеративной настройке.

Шаг 4. Пошаговая настройка ограничений по файлам

Самая частая причина «сломанных» приложений — неправильный список путей. Но именно здесь AppArmor даёт максимальную пользу: вы можете сделать так, чтобы Termux видел только те места, где вы действительно работаете.

Рекомендованный подход:

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

Пример уточнения (идея):

  # Разрешаем чтение проектов, но запись только в определённый каталог
  @{HOME}/projects/ r,
  @{HOME}/projects//build/ rwk,

  # Скрипты — только из заданной папки
  @{HOME}/scripts/ mrwix,

Такой контроль снижает ущерб при случайном запуске или подмене файлов.

Шаг 5. Ограничение выполнения и параметров (без избыточного «wix»)

Для безопасности важно не давать слишком широкие комбинации прав на выполнение. Комбинация разрешений типа mrwix (read, write, execute with inheritance) — сильная. Её следует применять только к действительно доверенным директориям.

Если вы запускаете свои программы, лучше:

Разрешить исполнение из каталога, где вы вручную поддерживаете набор доверенных скриптов/бинарников.
Свести запись в эти каталоги к минимуму (или сделать невозможной запись, если это не требуется).

Пример более строгого подхода:

  @{HOME}/scripts/ r,
  @{HOME}/scripts/ x,     # выполнение без разрешения записи

  @{HOME}/.local/share/termux-tmp/ rwk,  # отдельный каталог для временных артефактов

Это предотвращает сценарии, когда компрометированная среда сможет подменить исполняемые файлы на лету.

Шаг 6. Сеть: принцип минимизации (и только то, что нужно)

Если Termux используется для обновлений пакетов и общения с репозиториями, обычно требуются исходящие соединения. Но даже там можно минимизировать риск.

Правила сети в AppArmor часто зависят от вашей платформы и возможностей профилирования. На уровне концепции:

Если вам достаточно исходящих TCP — разрешите network inet stream и/или ограничьте по направлениям/адресам (если поддерживается).
Если IPv6 не используется — можно запретить inet6 на старте.
Не разрешайте лишние классы (например, экзотические сокеты), если у вас нет соответствующих задач.

Пример базового ограничения (идея):

  # Минимум: исходящие TCP
  network inet stream,

  # Если IPv6 не нужен — исключите:
  # network inet6 stream,

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

Шаг 7. Привязка и подключение профиля в систему

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

Положите файл профиля в место, читаемое AppArmor (часто это /etc/apparmor.d/).
Проверьте синтаксис и загрузите/перезагрузите профиль.
Убедитесь, что Termux-процесс попал под нужную политику.

Пример команд (адаптируйте под вашу систему):

sudo apparmor_parser -r /etc/apparmor.d/usr.bin.termux-base
sudo systemctl reload apparmor || true
sudo aa-status

Далее выполните сценарий использования Termux и наблюдайте, какие операции блокируются. Важно фиксировать точные причины отказов, чтобы корректно расширить профиль.

Шаг 8. Итерации: от «проходит» к «максимально строго»

Практика безопасности — итеративная. Начинайте с более мягкого профиля (чтобы терминал не «умирал»), а затем постепенно ужесточайте.

Типовой итерационный цикл:

Запуск типового сценария Termux.
Сбор списка denied/удалённых доступов из логов AppArmor.
Разбор: это действительно нужное действие или это потенциальный вектор атаки?
Обновление профиля только на минимально необходимую операцию.
Повторная проверка.

Отдельное правило зрелости: не расширяйте профиль «всё включить», даже если это быстро исправит ситуацию. Лучше точечно разрешить нужное действие и путь.

Шаг 9. Проверка качества: контроль безопасности и регрессии

После стабилизации профиля проведите проверки:

Тесты сценариев: обновления пакетов, работа с проектами, выполнение скриптов (только из разрешённых директорий).
Проверка устойчивости к ошибкам: корректно ли Termux ведёт себя при попытке доступа к запрещённым путям (ожидаемо — deny).
Тесты «на последствия»: убедитесь, что вредоносный скрипт не может уйти в неконтролируемые директории или подменить исполняемые файлы (при строгих правилах это ключевой результат).
Регрессия после обновлений: обновление Termux или пакетов может потребовать новых путей/бинарников. Планируйте периодическую повторную проверку.

Типовые ошибки при построении профиля

Слишком широкий доступ к домашнему каталогу (особенно на запись и выполнение). Это снижает эффект изоляции.
Разрешение выполнения из каталогов, где идёт запись (создаёт условия для подмены).
Отсутствие разделения доверенных и временных директорий (временные — должны быть rw, но выполнение там чаще всего не нужно).
Игнорирование сетевых потребностей (Termux может падать или вести себя неожиданно, если сеть слишком ограничена).
Отсутствие итераций с логами denied (профиль становится «догадкой», что почти всегда ведёт к компромиссам в безопасности).

Заключение

Глубокий аудит безопасности для Termux с построением собственного профиля AppArmor позволяет перевести защиту от общих рекомендаций к измеримому контролю доступа: Termux получает ровно те разрешения, которые необходимы под ваши сценарии, а нежелательные действия — блокируются политикой. Ключ к успеху — правильный сбор наблюдений, итеративная настройка правил (файлы, выполнение, сеть), и регулярная проверка после изменений в окружении.

Если хотите быстро и безопасно пройти этот путь с минимальным временем простоя — команда РыбинскЛАБ поможет с аудитом, проектированием профиля AppArmor, интеграцией и сопровождением под вашу инфраструктуру Termux.