Управление SELinux‑политиками и AppArmor‑профилями непосредственно из Termux для повышения привилегий безопасности

Termux — удобная среда для администрирования и лабораторных исследований в мобильных Linux‑окружениях. Однако управление SELinux‑политиками и AppArmor‑профилями напрямую из Termux имеет смысл только в безопасных сценариях: для аудита, отладки правил, автоматизации тестов и повышения предсказуемости разграничения доступа. Важно: любые шаги должны соответствовать требованиям безопасности и законодательным нормам РФ, а также опираться на официальные, допустимые методы развертывания политик в целевой системе.

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

Модель безопасности и правовые/операционные ограничения

SELinux и AppArmor — механизмы принудительного контроля доступа (MAC). Управление ими требует административных полномочий и обычно доступно только в рамках доверенного администрирования. Поэтому практический смысл “управлять из Termux” возможен, если:

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

Ниже будут рассмотрены шаги, направленные на аудит и корректную конфигурацию политики. Явных инструкций по обходу защит или несанкционированному повышению прав не будет.

Что именно управляется: SELinux и AppArmor

1) SELinux

В SELinux управление обычно включает:

Проверку режима (enforcing/permissive/disabled).
Аудит через логирование (AVC, denials).
Компиляцию и загрузку модулей или базовых политик (в зависимости от системы).
Работу с “policy modules” и проверку, какие правила активны.

2) AppArmor

В AppArmor управление обычно включает:

Проверку статуса загрузчика и наличия профилей.
Просмотр профилей и их текущего режима (enforce/complain/audit).
Загрузку/перезагрузку профиля.
Анализ логов (audit/syslog/journald в зависимости от системы).

Подготовка Termux под задачу

Termux сам по себе не “магически” получает доступ к ядру/политикам. Поэтому подготовка сводится к двум вещам: (1) корректному окружению пользователя и инструментам, (2) надежной передаче файлов конфигурации/политик и (3) контролю результата.

На практике вам понадобятся:

Набор утилит: coreutils, procps, curl/wget (при необходимости), а также инструменты, специфичные для SELinux/AppArmor в целевой ОС.
Доступ к логам/профилям/файлам политик на хосте (через допустимый механизм: bind‑mount, общий каталог, SSH/SFTP в рамках локальной админ‑сети).
Утилиты для сборки/валидации: например, для SELinux — инструменты работы с policy (на стороне системы), для AppArmor — утилиты загрузки профилей.

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

pkg update
pkg upgrade
pkg install coreutils procps ndk-sysroot curl

Дальше — самое важное: как вы попадёте на файлы политик. Для большинства задач безопаснее использовать локальную админ‑сеть (например, VPN для создания локальной сети между устройством и стендом), а затем обращаться к целевой машине по SSH/SFTP с минимальными правами. Это не обход блокировок, а управляемая инфраструктура для администрирования.

Практика: построение “потока” управления из Termux

Рекомендуемый безопасный подход выглядит так:

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

Шаг 1. Проверка статуса SELinux

На целевой системе (хосте) чаще всего доступны команды вроде:

getenforce
sestatus

Если у вас есть доступ к консоли хоста через допустимый канал, запустите проверки там. В Termux можно автоматизировать сбор результатов при помощи SSH, если такой доступ разрешён политикой вашей организации:

ssh admin@HOST "getenforce; sestatus"

Зачем это нужно: чтобы понимать, активны ли ограничения SELinux и можно ли тестировать в permissive/complain‑подобном режиме (если это предусмотрено процедурой).

Шаг 2. Аудит SELinux отказов (AVC)

Для анализа отказов применяют просмотр логов AVC. Конкретный источник зависит от дистрибутива и настройки journald/rsyslog. В общем виде:

ausearch -m avc -ts recent
# или
journalctl -t setroubleshoot
journalctl -k --grep=avc

Важная практика: сначала собирайте примеры отказов и идентифицируйте, какой домен/тип и какой объект затронут. Это позволяет писать минимально необходимые правила.

Шаг 3. Подготовка изменений SELinux

Безопасная последовательность для модификаций SELinux:

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

Точные команды зависят от механизма (модули policycoreutils, custom modules, distro policy build system). Пример типового паттерна (не универсален на все системы):

# гипотетический пример на стороне хоста (форматы могут отличаться)
make -f /usr/share/selinux/devel/Makefile
semodule -i mymodule.pp
semodule -l

Если вы работаете через Termux, обычно проще готовить файлы локально и передавать их на хост. Например, через SFTP:

sftp admin@HOST
put mymodule.te
put mymodule.pp
bye

Шаг 4. Актуализация политики и контроль результата

После загрузки модуля проверьте:

Не появилось ли критических отказов для ключевых сервисов.
Снизилось ли число AVC по ранее проблемным сценариям.
Не вырос ли риск за счёт слишком широких правил.

Проверка активных модулей:

semodule -l

И повторный анализ логов AVC — обязательно “до/после”.

Практика: AppArmor — профили и режимы

Шаг 1. Проверка статуса AppArmor

На хосте обычно применяют:

aa-status
# и (иногда)
apparmor_status

Если у вас есть доступ по SSH:

ssh admin@HOST "aa-status"

Шаг 2. Просмотр профилей и логов

Список профилей:

ls /etc/apparmor.d
# и/или
aa-status --profiled

Логи нарушений — зависят от системы. Часто используют:

journalctl --grep=apparmor
# или
dmesg | grep -i apparmor

Смысл тот же: сначала аудит и трассировка, потом правка профиля.

Шаг 3. Изменение профиля и перевод в нужный режим

Типовая безопасная тактика: сначала тестировать изменения в режиме, который позволяет не блокировать критические операции, а фиксировать нарушения (например, “complain” в зависимости от схемы). После валидации — переводить в enforce.

Переходы выполняются средствами AppArmor. Пример общего вида (на конкретной системе команды могут отличаться):

apparmor_parser -r /etc/apparmor.d/PROFILE
# затем контроль состояния
aa-status
# при необходимости переключить режим профиля (если поддерживается вашей схемой)

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

Как организовать управление “из Termux” без небезопасной автоматизации

Практически безопасная схема для администрирования:

Termux выступает “оператором” и интерфейсом для запуска сценариев.
Фактическая загрузка/перезагрузка политик выполняется на хосте под контролем admin‑учётной записи.
Сценарии включают журналирование: сохраняйте вывод команд и результаты проверок.
Всегда есть план отката: резервная копия профилей/модулей до изменений.

Пример скриптового каркаса (концептуально) для удалённого запуска проверок и применения изменений:

ssh admin@HOST '
set -e
echo "=== SELinux status ==="
getenforce || true
echo "=== AppArmor status ==="
aa-status || true
echo "=== Deploy step ==="
# команды загрузки — только если вы уверены и имеете разрешение
# semodule -i mymodule.pp
# apparmor_parser -r /etc/apparmor.d/PROFILE
echo "=== Post-check ==="
# повторная диагностика
aa-status || true
'

Обратите внимание: такие команды должны быть применимы именно к вашему стенду и выполняться с разрешения владельца/администратора.

Общие принципы минимизации привилегий

И SELinux, и AppArmor по-настоящему эффективны, когда правила минимальны:

Разрешайте только то, что нужно сервису (минимальные пути, минимальные операции, точные типы/домены).
Сначала — логирование/наблюдение, затем — enforcement.
Не делайте “глобальные” исключения по умолчанию: это снижает защищённость.
Фиксируйте контекст: чем точнее вы понимаете “почему отказ произошёл”, тем безопаснее получится правило.

Типовые ошибки

Слишком широкие допуски: “разрешить всё” кажется быстрым, но снижает защищённость.
Отсутствие аудита “до/после”: невозможно доказать, что проблема решена корректно.
Игнорирование обратимости: при ошибке нет быстрого отката.
Запуск без проверки статуса: если политика выключена или в другом режиме, вы можете неверно интерпретировать результат.

Заключение

Управление SELinux‑политиками и AppArmor‑профилями непосредственно из Termux — это практичный способ автоматизировать администрирование и повысить наблюдаемость при настройке MAC‑контроля. Безопасная стратегия заключается в том, чтобы Termux выступал управляющим интерфейсом: выполнял аудит, сбор доказательств, подготовку изменений и запуск корректного развертывания на стороне хоста с административными полномочиями. Такой подход помогает повышать привилегии не “обходом защит”, а через продуманную минимизацию прав и управляемое улучшение политики.

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