Вкратце о проблеме: SELinux не защищает файлы и каталоги, помеченные как httpd_sys_content_t, от записи, удаления или изменения при создании нового / настраиваемого корня документа.
Я воспроизвел это поведение дважды на разных сборках сервера. Среда чистая, свежая установка CentOS 7. Полностью пропатчен через yum. репо эпл установлено. установлен apache, php, mysql (mariadb), phpmyadmin.
SELinux включен по умолчанию в CentOS 7. getenforce и sestatus подтверждают, что SELinux запущен.
Я создал простой виртуальный хост в apache с корневым каталогом документа, установленным на: / web / sites / test1
Сначала все работает как положено. SELinux не позволит apache отображать этот веб-сайт, пока я не сделаю следующее:
semanage fcontext --add --type httpd_sys_content_t "/web(/.*)?"
semanage fcontext --add --type httpd_sys_content_t "/web/sites(/.*)?"
restorecon -Rv /web
Как и ожидалось, после этого виртуальный хост заработал.
Однако странное поведение заключается в том, что после установки wordpress на этом виртуальном хосте я могу загружать изображения и тому подобное через wordpress, хотя контекст httpd_sys_content_t не должен позволять этого (согласно моему пониманию).
Я подтвердил, что все файлы в каталоге wordpress правильно помечены как тип: httpd_sys_content_t
Тем не менее, wordpress все еще может писать в каталог (если это позволяют устаревшие разрешения для файлов).
Я придумал одно решение: типичное / ожидаемое поведение восстанавливается после полной перемаркировки файловой системы:
touch /.autorelabel
reboot
После перезагрузки я должен использовать контекст httpd_sys_rw_content_t, как и ожидал. Но я хотел бы более четко понять, почему такой шаг необходим, поскольку я читал, что полная перемаркировка редко (если вообще когда-либо) требуется. Есть ли какие-нибудь более простые и менее радикальные способы заставить SELinux вести себя так, как ожидалось?
Чтобы быть более кратким: следует ли мне ожидать, что в такой ситуации придется выполнять "touch /.autorelabel"? Есть ли способ лучше? Должен ли он просто работать без каких-либо дополнительных действий (и, следовательно, это ошибка CentOS 7 «из коробки»)?
Комментарии @dawud неверны. Проверены разрешения DAC первый. Если они запрещают доступ, то процесс получает отказ в разрешении. Если DAC разрешает доступ, то проверяется MAC-политика selinux. Если DAC разрешает доступ, но MAC запрещает доступ, то доступ запрещается. DAC никогда не может переопределить MAC. Диаграмма
Ваш плагин Wordpress должен быть помечен httpd_sys_script_exec_t и поэтому работать как httpd_sys_script_t. я использовал apol, инструмент анализа политик, чтобы просмотреть политику на виртуальной машине CentOS. Оказывается, когда httpd_enable_cgi и httpd_unified включены логические значения, включены разрешающие правила, которые дают процессам с httpd_sys_script_t пометить полный доступ к объектам, помеченным httpd_sys_content_t.
Ниже перечислены правила нарушения, которые включаются (обозначены комментариями [Включено]). Обратите внимание, что httpdcontent - это атрибут SELinux, назначенный в политике всем httpd_sys*content_t ярлыки, поэтому эти правила применяются ко всем из них.
allow httpd_sys_script_t httpdcontent : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ; [Enabled]
allow httpd_sys_script_t httpdcontent : file { ioctl read write create getattr setattr lock append unlink link rename entrypoint open } ; [Enabled]
allow httpd_sys_script_t httpdcontent : lnk_file { ioctl read write create getattr setattr lock append unlink link rename } ; [Enabled]
Также включены правила перехода типов, которые вызывают создание новых объектов httpd_sys_script_t процесс в httpd_sys_content_t-labeled каталог, который будет помечен httpd_sys_rw_content_t.
type_transition httpd_sys_script_t httpd_sys_content_t : dir httpd_sys_rw_content_t; [Enabled]
type_transition httpd_sys_script_t httpd_sys_content_t : file httpd_sys_rw_content_t; [Enabled]
type_transition httpd_sys_script_t httpd_sys_content_t : lnk_file httpd_sys_rw_content_t; [Enabled]
Я проверил Документы Red Hat Apache SELinux и нашел это:
httpd_unified
Если этот параметр включен, это логическое значение обеспечивает полный доступ httpd_t ко всем типам httpd (то есть выполнение, чтение или запись sys_content_t). При отключении существует разделение между веб-контентом, который доступен только для чтения, доступен для записи или исполняемый. Отключение этого логического значения обеспечивает дополнительный уровень безопасности, но добавляет административные издержки, связанные с необходимостью индивидуальной маркировки сценариев и другого веб-контента на основе доступа к файлам, который должен иметь каждый.
Попробуйте выключить httpd_unified и посмотрите, как вы ожидаете.