Глубокая настройка SELinux/AppArmor в Termux для ограничения привилегий приложений

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

Цель этой статьи — показать подход к «глубокой» настройке ограничений через механизмы SELinux и AppArmor (в зависимости от того, что реально доступно на вашем устройстве), чтобы уменьшать поверхность атаки Termux и отдельных приложений/скриптов. Важно: в рамках законодательства РФ мы не рассматриваем обходы защит, выключение безопасности «в обход» или техники, нацеленные на нарушение политики ОС. Мы фокусируемся на легальных и безопасных способах управления доступом: проверка текущего состояния, принцип наименьших привилегий, сегментация и корректная политика.

SELinux и AppArmor в двух словах: что реально может работать на Android

На Android по умолчанию чаще применяется SELinux. На большинстве сертифицированных устройств SELinux работает в режимах Enforcing или Permissive (в зависимости от модели/прошивки). AppArmor на Android встречается редко и обычно требует нестандартных сборок или конкретных окружений.

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

Шаг 1. Инвентаризация: проверяем текущие ограничения

Начните с проверки статуса SELinux и доступности AppArmor. В Termux выполните:

getenforce

getenforce 2>/dev/null; getenforce

Далее можно посмотреть, видит ли система признаки AppArmor:

ls /sys/kernel/security 2>/dev/null

И получить подсказки по файловой системе безопасности:

mount | grep -E 'securityfs|apparmor|selinux' || true

Если SELinux в режиме Enforcing, это хороший знак: политика активно применяется. Если Permissive, ограничения могут не блокировать действия, а лишь логировать нарушения — тогда стоит уделить больше внимания логам и реальной политике.

Шаг 2. Ограничение в рамках Termux: принцип наименьших привилегий и изоляция

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

• Разделения рабочих профилей: разные директории, отдельные переменные окружения, отдельные скрипты.
• Минимизации прав на файловую систему: аккуратные permissions в ваших каталогах.
• Сокращения системного контакта: не монтировать лишнее, не использовать лишние сетевые инструменты без необходимости.
• Локального контроля запуска: ограничение того, какие команды и утилиты реально доступны пользователю.

На практике хорошая стратегия: сделать «песочницу» на уровне файлов и исполнения (в рамках возможностей Android) и опираться на SELinux как на границу доступа к системе.

Шаг 3. Работа с политикой SELinux: что можно делать легально и практично

Тонкость: «глубокая настройка SELinux» обычно подразумевает внесение изменений в политики на уровне устройства (теоретически — через правки compiled policy и загрузку/применение). Но в Android это часто недоступно без небезопасных модификаций системы. Поэтому мы будем корректно использовать подход:

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

Чтобы понять текущий SELinux контекст, используйте:

id -Z 2>/dev/null || true

ls -Z /data 2>/dev/null | head -n 5 || true

Если команда id -Z недоступна, можно попытаться увидеть контексты для исполняемых файлов и каталогов Termux:

ls -Z "$HOME" 2>/dev/null | head -n 20 || true

Далее — сбор логов о блокировках. SELinux обычно пишет в журнал ядра/системы. В Termux доступ к журналам может быть ограничен, но попытаться стоит:

dmesg 2>/dev/null | grep -i 'avc:' | tail -n 50

Если dmesg ограничен, используйте логирование Android через доступные команды (при наличии):

logcat -d 2>/dev/null | grep -i 'avc' | tail -n 200

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

Шаг 4. «Глубина» через структуру: как уменьшать запросы к SELinux

Вы не обязательно переписываете SELinux-политику, чтобы получить существенный эффект. Важен принцип: чем меньше действий и системных интерфейсов вы используете, тем меньше шансов на небезопасные доступы.

Практические меры для Termux:

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

В Termux можно усилить права на ключевые файлы (внутри вашего пространства). Пример:

chmod 700 "$HOME"
chmod 700 "$HOME/.ssh" 2>/dev/null || true
chmod 600 "$HOME/.ssh/"* 2>/dev/null || true

Шаг 5. AppArmor (если доступен): подход к профилям без «магии»

Если в вашей системе реально присутствует AppArmor и вы можете работать с профилями, придерживайтесь следующего корректного подхода:

• Сначала проверьте, какие профили загружены:

aa-status 2>/dev/null || true

• Проверьте доступность каталога профилей:

ls /etc/apparmor 2>/dev/null || true
ls /sys/kernel/security/apparmor 2>/dev/null || true

• Далее — оцените ограничения для процесса Termux (если возможно) и собирайте логи.

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

Шаг 6. Практический план: как сделать политику безопаснее без взлома системы

Ниже — практический план, который даёт измеримый результат даже без изменения SELinux-политик ядра:

1. Соберите диагностику: режим SELinux (getenforce), контексты (id -Z или ls -Z), логи блокировок (dmesg / logcat с avc).
2. Минимизируйте доступ Termux к данным: ограничьте разрешения в Android для Termux по принципу «только нужное».
3. Разведите роли: отдельные директории под рабочие проекты, секреты и временные файлы.
4. Контролируйте права файлов: применяйте строгие chmod для ключей, конфигов и скриптов.
5. Ограничьте запуск утилит: не добавляйте в $PATH и не используйте компоненты, которым вы не доверяете.
6. Ведите журнал «что не работает»: если SELinux блокирует запросы, фиксируйте причины по avc: denied, чтобы оптимизировать конфигурацию в безопасную сторону.

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

Шаг 7. Типовые сценарии использования и соответствующие ограничения

Рассмотрим несколько распространённых задач и как они могут пересекаться с SELinux:

• Локальная разработка и сборка: основная часть операций — в ваших директориях. На практике SELinux почти всегда позволяет работу в пользовательском пространстве Termux, но блокирует попытки доступа к «чужим» системным путям.
• Сетевые инструменты: проблемы обычно не в SELinux как таковом, а в правах Android/приложения и в том, какие сокеты/интерфейсы доступны приложению. Не стремитесь открывать лишние возможности.
• Работа с файлами вне Termux: здесь SELinux и политика доступа Android могут блокировать путь. Решение — корректно использовать разрешённые механизмы доступа (в рамках настроек и каталога, куда Android даёт доступ приложению).

Если вы используете VPN, то корректный сценарий — создание локальной сети для тестирования или изоляции трафика. Не используйте VPN как инструмент обхода блокировок.

Шаг 8. Контроль качества: метрики и проверка изменений

Чтобы убедиться, что «глубокая настройка» действительно дала эффект, используйте следующие индикаторы:

• Снижение числа AVC отказов: после внесения изменений в конфигурацию и дисциплину работы должно быть меньше отказов и попыток «куда-то лезть».
• Сужение доступа файлов: секретные данные защищены строгими правами и изолированы.
• Минимум установленного софта: перечень пакетов Termux максимально компактный под задачу.
• Предсказуемость: команды выполняются без «случайных» путей к системным ресурсам.

Безопасность и соответствие правовым требованиям

Любая работа с политиками SELinux/AppArmor должна проводиться в рамках законных и безопасных процедур. Мы не рекомендуем использовать методы, которые подразумевают несанкционированное вмешательство в системные компоненты или обход защит. В контексте РФ важно придерживаться общих принципов: не нарушать целостность ОС, не использовать небезопасные модификации без необходимости и оценивать риски для устройства и данных.

Заключение

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

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