Перейти к содержанию

SELinux: определить режим и диагностировать отказ

SELinux — механизм обязательного разграничения доступа на уровне ядра. Он может препятствовать операции даже если UNIX-права и ACL выглядят правильными. В SPEC НАЙС.ОС присутствуют selinux-policy и policycoreutils, но это ещё не доказывает, что SELinux включён и находится в enforcing во всех образах. До изменений выясните фактический режим, набор политик и контекст повреждённого файла.

Состояние SELinux

cat /etc/selinux/config 2>/dev/null || true
getenforce 2>/dev/null || true
sestatus 2>/dev/null || true
cat /proc/cmdline
ls -Z /etc/passwd 2>/dev/null || true

Возможные значения: Enforcing (решения исполняются), Permissive (отказы логируются, но политика не блокирует операции) и Disabled (SELinux фактически отключён). Содержимое /etc/selinux/config может отличаться от состояния текущей загрузки. Отдельные подсистемы могут использовать другие механизмы контроля доступа.

Почему chmod не помогает

Классические права DAC и MAC SELinux — разные проверки. Если веб-сервис не может прочитать файл, хотя его uid совпадает, проверьте:

namei -l /srv/example/file
ls -lZ /srv/example/file
journalctl -b | grep -Ei 'avc:|denied|selinux' | tail -80

Доступность и формат AVC-журналов зависят от установленного audit/ядра. Если ausearch установлен, можно искать сообщения AVC по времени/службе. Отсутствие записи AVC само по себе не доказывает, что проблема не в SELinux.

Безопасная методика расследования

  1. Зафиксируйте режим, policy и затронутый процесс.
  2. Проверьте DAC-права и правильный контекст (ls -Z, ps -eZ).
  3. Прочитайте отказы AVC/audit, определите источник и целевой объект.
  4. Сверьте ожидаемый контекст и текущую метку.
  5. Используйте документированный способ восстановления контекста (restorecon) для подтверждённого пути, а не массовую перенастройку всей системы.
  6. Если нужны дополнительные разрешения, подготовьте минимальную политику в тестовой среде, с согласованием ИБ.

Не делайте этого для «починки»

  • setenforce 0 без учёта политики и возврата режима.
  • chmod -R 777 на приложении.
  • Массовая перезапись контекстов chcon -R без понимания policy.
  • Отключение SELinux параметром ядра на production-сервере.

Взаимодействие с контейнерами

Контейнерные движки могут использовать метки файлов и томов. При bind-mount нужно отдельно проверить требования SELinux, права и настройку контейнера. Не делайте глобальный вывод о проблеме Docker по одному AVC.

Источники: Core/selinux-policy/SPECS/selinux-policy.spec, Core/policycoreutils/SPECS/policycoreutils.spec; фактический режим требует проверки экземпляра.