Настройка SELinux в Red OS — принудительный контроль доступа

Сразу включите принудительную политику: setenforce 1. Если этого не сделать – ограничения не применяются. Не верите? Проверьте: getenforce. Ответ не «Enforcing»? Тогда всё зря. Откатите и начните сначала.

Не используйте Permissive в продуктиве. Никогда. Это ловушка. В логе будет красиво, на деле – дыра размером с ядро. Подмените режим только временно – setenforce 0 – но сразу возвращайте назад после анализа.

Проверьте текущую политику: sestatus. Обратите внимание: в Red OS предустановлен targeted. Это значит – только избранные службы под наблюдением. Остальные живут в анархии. Хочется жёстко? Меняйте политику на mls или strict. Это уже другая лига. Работает не всё, зато надёжно. Подходит только тем, кто не боится зависаний.

Важно: при смене политики потребуется пересоздание всех контекстов! Команда touch /.autorelabel && reboot – ваш спасательный круг. Без неё – хаос.

Проверьте контексты: ls -Z. Видите нестандартный тип? Значит, что-то пошло не по плану. restorecon -Rv /путь помогает, если система ещё жива. Если нет – готовьтесь к ручной корректировке: chcon спасает, но это костыль. Правьте файлы .te, собирайте модули через checkmodule и semodule_package.

Пример: веб-сервер не видит каталог с контентом? chcon -t httpd_sys_content_t /var/www/html. Работает мгновенно. Но только до следующей проверки. Постоянное решение – semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?" и restorecon -R /var/www/html.

Не игнорируйте аудит: ausearch -m avc и audit2allow покажут, что именно блокируется. Если вы всё ещё гадаете, почему не запускается nginx – это ваш ответ. Добавьте правило, соберите модуль, примените: semodule -i модуль.pp. Всё. Работает.

Помните: отключать ограничения – это не решение. Это капитуляция. И она стоит дорого.

Особенность Red OS: модули безопасности подшиваются жёстко. Нестандартные политики могут конфликтовать с установленными пакетами. Всегда проверяйте зависимости. semodule -l покажет всё, что сейчас в системе. Не добавляйте лишнего. Удалить – сложно.

Не путайте типы: user_t – не то же, что staff_t или sysadm_t. Уровень доступа – разный. Ошибка в профиле пользователя – и вы больше не root, а беспомощный наблюдатель. Проверьте id -Z для уверенности.

Проверка текущего режима SELinux и смена его на Enforcing

Проверь статус текущей политики немедленно. Команда:

getenforce

Ответ может быть один из трёх: Enforcing, Permissive или Disabled. Первый – порядок. Второй – полумера. Третий – бардак.

Дополнительно проверь конфигурацию в файле:

cat /etc/selinux/config

Смотри на строку:

SELINUX=

Если там не enforcing – у тебя проблема. Режим Enforcing не включится автоматически после перезагрузки без правки этого файла.

Важно: текущий режим можно изменить на лету, но без изменения конфигурационного файла при перезагрузке он сбросится.

Меняешь активный режим сразу:

setenforce 1

Проверь ещё раз:

getenforce

Если остался Permissive – ищи причину. Возможно, ядро загружено с параметром selinux=0. Проверяй строку загрузки:

cat /proc/cmdline

Если видишь selinux=0 – срочно правь загрузчик. Пример для GRUB2:

1. Открыть /etc/default/grub
2. Удалить selinux=0 из строки GRUB_CMDLINE_LINUX
3. Обновить конфигурацию GRUB: grub2-mkconfig -o /boot/grub2/grub.cfg
4. Перезагрузиться

Теперь к конфигу /etc/selinux/config. Убедись, что строка:

SELINUX=enforcing

и не тронута посторонними руками. Часто пользователи отключают механизм, не понимая последствий.

Внимание: при переключении режима возможны конфликты с уже установленными сервисами. Всегда проверяй журналы: journalctl -xe

Если нужен режим на постоянной основе – только через конфигурационный файл. Команда setenforce работает до первого ребута.

Проверка завершена? Отлично. Порядок наведен.

Создание и применение собственных SELinux-политик для служб

Не пытайтесь подгонять системные службы под типовые контексты. Проще сгенерировать модуль под задачу. Используйте audit2allow совместно с checkmodule и semodule_package.

Сначала включите логирование отказов:

setenforce 1

Запустите нужную службу. Допустите ошибки. Затем извлеките события из логов:

ausearch -m avc -ts recent > denied.log

Создайте шаблон модуля:

audit2allow -i denied.log -M custom_service

Результатом будет два файла: custom_service.te и custom_service.pp. Проверьте .te вручную. Там часто бывает мусор. Удаляйте сомнительные строки. Особенно те, что связаны с unconfined_t.

Подключите модуль:

semodule -i custom_service.pp

Проверьте, что модуль загружен:

semodule -l | grep custom_service

Пример: создаем модуль для сервиса, который обращается к нестандартному каталогу /data/backups.

В custom_service.te появится что-то вроде:

allow httpd_t var_t:dir { read getattr open };

Замените var_t на собственный тип:

semanage fcontext -a -t custom_data_t "/data/backups(/.*)?"
restorecon -Rv /data/backups

Добавьте правило в .te:

allow httpd_t custom_data_t:dir { read getattr open };

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

checkmodule -M -m -o custom_service.mod custom_service.te
semodule_package -o custom_service.pp -m custom_service.mod
semodule -i custom_service.pp

Важно: не используйте обобщенные типы вроде tmp_t, var_t и usr_t. Они часто блокируются базовой политикой и создают ложное ощущение работоспособности.

Если модуль отрабатывает нестабильно, используйте semanage permissive -a custom_service_t для отладки. После тестов удалите режим:

semanage permissive -d custom_service_t

Для удаления модуля:

semodule -r custom_service

Внимание! После обновлений системы может потребоваться пересборка модулей. Особенно если менялись зависимости типа policycoreutils.

Не забывайте: собственные политики – это не магия, а хирургия. Делайте их точечно. Без фанатизма. Чем меньше правил – тем выше устойчивость.

Анализ журналов SELinux и устранение причин блокировок доступа

Первое действие – просмотр лога. Открываем системный журнал с фильтрацией по ключевому слову:

ausearch -m avc -ts recent

type=AVC msg=audit(1680000000.123:456): avc:  denied  { write } for  pid=1234 comm="nginx" name="cache" dev="sda1" ino=1234567 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_cache_t:s0 tclass=dir

Кто пытался? comm=»nginx». Что делал? { write }. Где? name=»cache» с меткой var_cache_t. А процессу положено? Нет, он в домене httpd_t, а на директорию таких прав нет.

Далее – генерация предложенного разрешения:

audit2allow -a

Или по конкретной записи:

ausearch -m avc -ts recent | audit2allow

audit2allow -M fix_nginx_cache

И активируем:

semodule -i fix_nginx_cache.pp

Внимание! Всегда проверяйте, не расширяет ли модуль лишние права. Не доверяйте слепо результатам audit2allow.

Ошибки, связанные с типами меток: применяйте повторное маркирование:

restorecon -Rv /var/cache/nginx

При нестандартных путях задавайте метки вручную:

semanage fcontext -a -t httpd_cache_t "/custom/path(/.*)?"

После чего:

restorecon -Rv /custom/path

Важно помнить: если объект не промаркирован или метка задана произвольно – любые попытки доступа будут рубиться без пощады.

Контроль перезапуска служб после внесения изменений обязателен:

systemctl restart nginx

Проверка повторная. Если блокировка исчезла – модуль работает. Если нет – снова в ausearch. Ошибки чаще не там, где их ждут.

Для поиска немых конфликтов используйте:

sealert -a /var/log/audit/audit.log

Инструмент выдаст подробную расшифровку и рекомендации. Иногда – чрезмерные. Но игнорировать нельзя.

Застряли? Посмотрите список всех активных политик:

semanage boolean -l

Многое решается через смену логических переменных:

setsebool -P httpd_can_network_connect on

Запомните: каждая ошибка в журнале – это прямой путь к устранению сбоя. Не маскируйте. Разбирайтесь.