Рекомендации, причины проблем и основные концепции

Причины перевода в permissive/disable
Причины проблем
Основные понятия в SELinux
Краткий итог по решению «проблем» с SELinux

Окружение

• Версия ОС: 8
• Конфигурация ОС: Рабочая станция
• Редакция ОС: Стандартная

Причины перевода в permissive/disable

1. Во время развертывания сервиса SELinux часто переводится в режим permissive, чтобы проверить его работоспособность, а также выявить все потенциальные проблемы по уведомлениям SELinux. В случае использования режима enforce при проблемах сервис не будет работать корректно, а в уведомлениях будет только одна из причин. Так же уведомления могут отсутствовать, если в политиках предусмотрена настройка (seboolen). Отключенные разрешения описаны как dontaudit, и это также относится к режиму permissive.

2. Пакеты партнёров нередко запускают сервисы сразу в процессе установки, что, в принципе, является некорректной практикой. Кроме того, если продукт не имеет собственных политик, а в скриплетах пакета не производится настройка контекстов исполняемых файлов, то после запуска таких сервисов журнал аудита мгновенно начитает заполняться сообщениями, что не позволяет производить дальнейшую работу. В таком случае рекомендуется перевести SELinux в режим disable, отключить запуск сервисов, перевести SELinux в режим permissive, произвести разметку исполняемых файлов, произвести настройку сервиса. Далее, убедившись в работоспособности сервиса, продолжайте действовать, анализируя уведомления. Режим disable не рекомендуется, т. к. не происходит маркировка вновь создаваемых файлов, что может вызвать проблемы при последующем включении SELinux.

Причины проблем

1. При обновлении selinux-policy (как правило, при обновлении операционной системы) метки безопасности отличаются в старых и новых политиках. Новые модули привносят новые файловые контексты, также политики могут дробиться для сужения разрешений. Решение — произвести переразметку файловой системы. touch /.autorelabel && reboot. Или в kernel cmdline также можно добавить параметр autorelabel=1. Иногда требуется добавить ещё и enforce=0 на время разметки. Как правило, такое требуется, если SELinux был отключен и разметка файловой системы никогда не проводилась.

2. Наследование домена запускающего процесса. Уведомления SELinux не дают чёткого понимания о причине. Тут нужно смотреть домен субъекта и тип объекта. Если домен init_t, то вероятнее всего он унаследовался от systemd, т.к. тип исполняемого файла был некорректный. В этом случае надо исправить контекст исполняемого файла и (или) systemd-юнит файла сервиса. Такое обычно происходит, когда исполняемые файлы и юнит файлы перемещают из других каталогов, т.к. при перемещении метки безопасности сохраняются аналогично дискреционным правам доступа.

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

4. Обновление ПО без коррекции политик. ПО может требовать новые ресурсы, которые не учтены в текущих политиках.

5. Компрометация. Причиной нарушений может быть реальная попытка несанкционированного доступа или действие вредоносного ПО. В такой ситуации уведомления SELinux свидетельствуют о корректной работе системы защиты, которая заблокировала подозрительную активность. 

Основные понятия в SELinux

RBAC (Role-based access control) — контроль на основе типах SELinux пользователей и их ролей. Используется пока ещё редко (политики редко описывают разрешения с учётом пользователей и ролей), более распространён и описан контроль на основе типов.

Type Enforcment — ограничения на основе типа или домена.

Domain Transition — переход домена. Например, когда процесс с доменом init_t(systemd) запускает sshd с типом ssh_exec_t, в соответствии с политикой, домен процесса sshd становится ssh_t. В случае отсутствия описания перехода — домен наследуется.

File Transition — переход типа файла. Например, процессу в домене ssh_t нужно создать файл в /tmp с типом tmp_t. Политика должна разрешать домену ssh_t доступ к типу tmp_t, но в этом нет смысла, т. к. в случае компрометации ssh_t получит доступ и ко временным файлам других процессов. Правильный подход заключается в том, чтобы создаваемые ssh_t временные файлы получали свой тип ssh_tmp_t и домену ssh_t было разрешено работать только с ним. Это и есть переход типа файла.

Краткий итог по решению «проблем» с SELinux

Если сервис имеет модуль политики (работает в собственном домене):

1. Проанализируйте уведомления.

2. Внесите необходимые изменения в модуль политики.

Если сервис не имеет модуля политики:

1. Запустите приложение в домене unconfind_service_t.

2. Напишите политику для приложения.

Дата последнего изменения: 21.10.2025

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.