Диагностика отказов SELinux: от записей AVC к исправлению меток

После переноса файлов сайта из исходного каталога в /srv httpd возвращает 403, хотя файлы доступны для чтения, а служба работает. В такой ситуации не следует сразу расширять права доступа или отключать SELinux. Обычные файловые права, настройки авторизации службы и принудительное управление доступом — три отдельных уровня проверки. На примере уже настроенного тестового виртуального хоста httpd в AlmaLinux 9 мы сопоставим неудачный запрос с записями AVC, исправим метки с сохранением изменений, а затем проверим работу службы и границы доступа.

1. Определяем рамки теста и фиксируем исходное состояние

Для выделенного сервера CloudDDR можно выбрать AlmaLinux 9. После оплаты посмотрите учётные данные в панели управления и подключитесь по SSH; если адресов несколько, используйте первый. Следующие действия требуют прав администратора. Выполняйте их только в изолированной тестовой среде: не перезаписывайте существующие рабочие каталоги и не меняйте адреса прослушивания или настройки межсетевого экрана.

Предполагается, что httpd уже установлен, а тестовый виртуальный хост и адрес для обращения к нему настроены. Сначала сохраните конфигурацию этого виртуального хоста и запишите исходное значение DocumentRoot. Если необходимых инструментов диагностики нет, установите соответствующий пакет, затем проверьте режим SELinux и состояние службы аудита:

sudo dnf install policycoreutils-python-utils
getenforce
sestatus
sudo systemctl status auditd --no-pager
sudo semanage fcontext -l -C
sudo semanage permissive -l

Ожидается, что глобальный режим — Enforcing, а домен, в котором работает httpd, не переведён отдельно в permissive. Если служба аудита работает некорректно, сначала восстановите сбор диагностических данных: отсутствие записей об отказах в журнале не доказывает, что доступ ничем не ограничен. Сохраните список локальных сопоставлений меток, чтобы позже отличить существовавшие правила от добавленных в ходе теста.

setenforce 0 — не исправление. Успешный запрос после отключения принудительного контроля даёт лишь подсказку для диагностики, но не доказывает, что всё будет работать после возврата в enforcing.

2. Сначала исключаем ошибки обычных прав и конфигурации

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

sudo install -d -m 0755 /srv/selinux-lab
printf 'selinux-lab-ok\n' | sudo tee /srv/selinux-lab/index.html
sudo chmod 0644 /srv/selinux-lab/index.html
namei -l /srv/selinux-lab/index.html
ls -ldZ /srv/selinux-lab
ls -lZ /srv/selinux-lab/index.html

В существующем тестовом виртуальном хосте измените корневой каталог документов и правила доступа к нему:

DocumentRoot "/srv/selinux-lab"

<Directory "/srv/selinux-lab">
    AllowOverride None
    Options -Indexes
    Require all granted
</Directory>

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

Задайте переменной оболочки CHECK_URL реальный тестовый URL с путём /index.html. Адрес должен соответствовать этому виртуальному хосту; не включайте в URL учётные данные. При запросе проверяйте тело ответа, а не только факт установления соединения:

sudo httpd -t
sudo httpd -S
sudo systemctl reload httpd
curl --fail --show-error "$CHECK_URL"

Если запрос не прошёл, сначала изучите журнал ошибок httpd. Отсутствие права на выполнение для родительского каталога, попадание в другой виртуальный хост и отказ по правилам авторизации могут давать похожие симптомы. Рекурсивное расширение прав в такой ситуации не устранит проблему меток, зато увеличит область доступных данных.

3. Определяем субъект, объект и действие по AVC

Запишите время запроса, воспроизведите неудачную операцию только один раз и найдите записи об отказах за тот же период:

sudo ausearch -m AVC,USER_AVC -ts recent -i
ps -eZ | grep '[h]ttpd'
matchpathcon -V /srv/selinux-lab/index.html

В AVC обращайте особое внимание на scontext, tcontext, tclass и запрещённые права доступа. scontext указывает домен процесса, инициировавшего доступ, а tcontext — контекст безопасности целевого объекта. Чтение файла и поиск в каталоге — разные действия; одного имени процесса для вывода недостаточно.

Сопоставьте путь, процесс и время из записи с неудачным запросом. Если запрещён поиск в каталоге, проверьте все каталоги по пути: исправление только конечного файла может не помочь. Если в записи нет пути, используйте номер события аудита, чтобы просмотреть другие записи того же события.

Отсутствие AVC ещё не означает, что SELinux точно ни при чём. Сначала проверьте временной диапазон, состояние аудита и фактический домен процесса службы. Если связанных подтверждений по-прежнему нет, вернитесь к проверке конфигурации приложения и обычных прав, а не добавляйте разрешающие правила вслепую. Не передавайте инструменту генерации политик и все старые записи об отказах: они могут относиться к другим службам.

4. Исправляем метки веб-содержимого с сохранением изменений

Для обычного статического содержимого, которое httpd должен читать, существующая политика предусматривает тип httpd_sys_content_t. Добавляйте точное сопоставление только тогда, когда диагностические данные показывают, что метки тестового пути не соответствуют его назначению:

sudo semanage fcontext -a -t httpd_sys_content_t \
    '/srv/selinux-lab(/.*)?'
sudo restorecon -Rv /srv/selinux-lab
matchpathcon -V /srv/selinux-lab/index.html
ls -lZ /srv/selinux-lab/index.html

Если точно такое же выражение уже существует, проверьте исходное правило и при необходимости измените его через -m, а не добавляйте новые правила поверх него. Выражение должно охватывать только тестовый каталог, а не назначать тип веб-содержимого всему /srv. semanage сохраняет сопоставление пути и типа, а restorecon применяет ожидаемый контекст к существующим файлам.

chcon меняет текущую метку напрямую, но не создаёт постоянного сопоставления, поэтому не заменяет этот шаг. Последующая перемаркировка может отменить временное изменение.

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

5. Проверяем результат и сохраняем возможность отката

Оставьте режим enforcing включённым и снова обратитесь к тому же адресу. Убедитесь, что тело ответа содержит selinux-lab-ok, и одновременно проверьте, не появились ли новые AVC, связанные с этим запросом. Затем ещё раз выполните restorecon, перезапустите тестовую службу и повторите запрос, чтобы убедиться, что исправление не зависит от временных меток или прежнего состояния процессов.

getenforce
sudo restorecon -Rv /srv/selinux-lab
sudo systemctl restart httpd
curl --fail --show-error "$CHECK_URL"
sudo ausearch -m AVC,USER_AVC -ts recent -i

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

Завершая эксперимент, сначала восстановите исходную конфигурацию виртуального хоста, проверьте синтаксис и перезагрузите конфигурацию, а затем удалите тестовый каталог. Можно удалить сопоставление, которое действительно было добавлено в этом эксперименте. Если изменялось существовавшее сопоставление, восстановите ранее записанный тип. После очистки выполните restorecon для путей, которые остаются.

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

Часто задаваемые вопросы