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

Termux остаётся одним из самых удобных инструментов для работы в Linux-среде на Android. Однако удобство неизбежно поднимает вопрос безопасности: как ограничить доступ приложений и сценариев к конфиденциальным файлам, потенциально опасным API и системным ресурсам.

Один из наиболее эффективных путей — использование механизмов обязательного контроля доступа (MAC), реализованных в SELinux. В этой статье мы разберём подход к применению SELinux в Termux через создание пользовательских политик (custom policy) для ограничения доступа к ресурсам. Материал носит прикладной характер и ориентирован на законное и безопасное администрирование в рамках возможностей вашей системы.

Важно: юридические и практические ограничения

В РФ применение программных средств должно соответствовать требованиям законодательства и условиям эксплуатации устройства. Эта статья не содержит инструкций по обходу защит, модификации систем “в обход правил” или действиям, которые могут нарушать политику безопасности ОС.

Практически, успешность включения SELinux и применения пользовательских политик зависит от модели устройства, версии Android и того, в каком режиме работает SELinux (Enforcing или Permissive). В ряде случаев стандартный пользователь Android не сможет менять политики без привилегий. Поэтому ориентируйтесь на легитимные методы, доступные в вашей среде.

Что именно даёт SELinux в контексте Termux

SELinux обеспечивает контроль доступа на основании:

контекста процесса (тип домена процесса);
контекста объекта (файлы/каталоги/устройства);
правил (allow/deny), описанных в политике;
режима работы (enforcing/permissive) и уровня доверия.

Для Termux это означает, что можно попытаться ограничить, какие файловые пути и какие типы объектов приложение может читать/писать, а также — какие системные интерфейсы оно может задействовать.

Предварительная подготовка: проверить режим SELinux и базовую информацию

Начните с диагностики. Даже если у вас нет полного контроля над политиками, полезно понять текущую конфигурацию.

1) Проверка режима SELinux (обычно выполняется через систему):

getenforce

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

2) Журналы (если доступны) для анализа отказов. На Android журналы SELinux часто видны через logcat или dmesg (зависит от сборки):

logcat -d | grep -i selinux

или:

dmesg | grep -i selinux

3) Контекст процесса Termux. Точный способ зависит от доступности утилит. Ищите наличие ps с колонками контекста или утилит для просмотра SELinux контекстов:

ps -Z

Если -Z недоступен, остаётся анализ через логи и изучение контекстов файловой системы.

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

Идея пользовательской политики: вы фиксируете, к каким объектам Termux не должен обращаться (или должен обращаться только определённым образом). Это могут быть:

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

Практический принцип: ограничивайте по минимуму, прежде чем добавлять исключения. Любая “широкая” политика быстро превращается в сложно контролируемую конструкцию.

Просмотр SELinux контекстов файлов и каталогов

Чтобы написать правило, нужно знать контекст объекта. Обычно для этого применяют ls -Z:

ls -Z /path/to/target

Если команды SELinux-тегирования недоступны напрямую, вы всё равно можете ориентироваться на то, что лог SELinux при отказе содержит ожидаемый/полученный контекст.

Пример сценария диагностики:

Вы пытаетесь выполнить действие в Termux (например, чтение файла/каталога).
Если SELinux блокирует, вы смотрите в логи запись о denials.
Из записи берёте domain (тип процесса) и type/context объекта.

Далее вы формулируете правило, которое разрешает только нужные действия или, наоборот, запрещает нежелательные (в зависимости от того, как устроена базовая политика и есть ли у вас возможность расширять её корректно).

Концепция пользовательских политик SELinux

Пользовательская политика — это добавление/расширение правил без полной перепаковки системной политики с нуля. На практике подход может различаться по платформам, но общая модель такая:

вы создаёте модуль политики (например, .te для описания);
конвертируете его в двоичный формат;
загружаете или подключаете модуль в системе;
проверяете, что изменения применились и не нарушили базовую работу.

Важный момент: безопасный путь — сначала добиться “узкой” политики с минимальными правами, затем расширять только при необходимости, используя журналы SELinux для подтверждения.

Скелет SELinux TE-модуля: структура правил

Ниже приведён общий каркас на уровне концепции. Точные имена типов и доменов будут вашими, полученными из диагностики (контекст процесса Termux и контекст целевых объектов).

// Пример каркаса (условные названия доменов/типов)
// Реальные типы нужно подставить по результатам анализа SELinux.

policy_module(termux_custom, 1.0)

require {
    type termux_t;          // домен процесса Termux (пример)
    type app_data_file_t;  // тип файлов (пример)
    class file { read write open getattr };
}

// Пример разрешения только на чтение (минимизация прав)
allow termux_t app_data_file_t:file { read open getattr };

Ключевой принцип: если вы хотите “ограничить доступ”, чаще всего правильно мыслить так — не расширять базовые разрешения, а добавлять только то, что нужно. Там, где вы ограничиваете, всё зависит от текущей политики: иногда проще “не давать” лишнего, чем пытаться жёстко запретить то, что уже разрешено глобально.

Практический рабочий процесс: от denial к правилу

Шаг 1. Проведите попытку доступа, который вы считаете лишним/нежелательным.

Шаг 2. Соберите denials:

logcat -d | grep -i "denied" | grep -i selinux

Шаг 3. Извлеките из сообщения:

source (domain процесса);
target (тип объекта);
class (класс объекта, например file);
операции (например read, write, open).

Шаг 4. Сформируйте модуль: добавляйте правило с минимальным набором разрешений. Если ваша цель — ограничить, то обычно правила либо не добавляют вовсе, либо добавляют “в узком режиме” (например, только чтение там, где требуется).

Пример: ограничение доступа Termux к определённому каталогу

Предположим, вы хотите, чтобы Termux не писал в конкретный каталог (или читал только часть). Тогда вам понадобится:

контекст домена Termux;
контекст типа файлов каталога;
какие действия разрешены сейчас и какие вы хотите минимизировать.

Пример условного модуля:

// termux_custom.te (условные типы; подставьте реальные значения)

policy_module(termux_custom, 1.0)

require {
    type termux_t;
    type restricted_dir_t;
    class dir { getattr open read search };
    class file { getattr open read };
}

// Разрешаем только чтение/поиск в каталоге
allow termux_t restricted_dir_t:dir { getattr open read search };

// Разрешаем только чтение файлов
allow termux_t restricted_dir_t:file { getattr open read };

Если попытка записи в этот каталог приводила к denial, то вы подтверждаете, что правила не расширяют доступ до записи. Если же базовая политика уже разрешает запись, “точечное” исправление может требовать более сложного подхода (например, создание более приоритетного правила или изменение меток объектов). Эти действия зависят от прав и сборки ОС.

Метод “через метки”: когда меняется контекст объектов

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

Концептуально это выглядит так:

Определить текущий контекст объекта.
Установить желаемый контекст (например, сделать каталог “restricted”).
Далее, описать правила доступа для домена Termux к этому типу.

Команды установки контекста зависят от наличия утилит и возможностей устройства. На большинстве систем с SELinux это может выглядеть как:

restorecon -Rv /path/to/target

или “ручная” установка возможна только при наличии нужных инструментов и привилегий (если доступно в вашей среде). Не пытайтесь применять небезопасные способы изменения системных настроек без понимания последствий.

Загрузка и проверка модуля

Поскольку на Android/Termux набор доступных утилит может отличаться, перечислим общие ориентиры. Как правило, workflow включает компиляцию policy и загрузку.

Условный пример шагов (на системах с доступными инструментами SELinux-разработчика):

// 1) Компиляция TE -> модуль
checkmodule -M -m -o termux_custom.mod termux_custom.te

// 2) Упаковка в policy package
semodule_package -o termux_custom.pp -m termux_custom.mod

// 3) Загрузка модуля
semodule -i termux_custom.pp

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

Валидация: убедиться, что ограничения реально работают

После внедрения политики проверьте:

что Termux продолжает выполнять требуемые вами задачи;
что нежелательные действия действительно блокируются (или не получают разрешения);
что в логах нет неожиданных отказов для “нормального” сценария.

Для этого используйте воспроизводимые тесты. Например:

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

Снова собирайте denials и сопоставляйте их с ожидаемым поведением.

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

Неправильные типы: правила пишутся под неверные context/тип объекта. Итог — неработающая политика или неожиданные побочные эффекты.
Слишком широкие разрешения: “разрешить всё, что нужно для теста”, а затем забыть сузить. Это ухудшает безопасность.
Отсутствие режима Enforcing: в Permissive кажется, что всё “работает”, но блокировки фактически не применяются.
Неучтённые зависимости: Termux-процессы могут обращаться к вспомогательным ресурсам (в том числе через библиотеки/плагины), и “узкая” политика может сломать повседневные сценарии.
Попытка “обойти” безопасность вместо её настройки: если базовая политика запрещает критичное — не старайтесь “отменить” запреты без крайней необходимости и анализа рисков.

Заключение

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

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