Что такое Security Enchanced Linux или Линукс с улучшенной безопасностью можно почитать, например, в Wikipedia. Улучшенная безопасность это в том числе и дополнительные ограничения и ошибки приложений и следовательно дополнительное время на их анализ и устранение.

Столкнувшись с реализацией SELinux в CentOS многократно попадал в различные тупиковые ситуации. Главным образом из-за незнания методологии - каким путем идти в той или иной ситуации. И какие вообще существуют методы решения SELinux конфликтов. Пути приходилось нащупывать в полной темноте местами тускло освещаемой маячками других первопроходцев.

Вобщем материалы по конкретным решениям есть, но цельной картины долго не удавалось увидеть. Сей труд представляет из себя крупную мозаику, которую каждый уже сможет дальше детализировать с помощью Интернета.

SELinux вводит дополнительные ограничения на доступ процессов к ресурсам. Сначала отрабатывает традиционная система безопасности, потом наступает очередь SE. Многие приложения естественно ничего об этом не знают.

Убедиться в том, что виноват имеено SE можно изменив режим его работы. Их три: enforcing, permissive и disable, соответственно, применение ограничений, логирование ограничений без применения и полное отключение SELinux. Установливаются режимы через переменную SELINUX в файле /etc/selinux/config. Применение режима произойдет после перезагрузки.

Если виновность SE установлена надо копать дальше, в логах:

/var/log/audit/audit.log
/var/log/messages

Ищем строки с avc: denied. Для удобства копания можно использовать графическую утилиту SEALERT входящую в пакет SETROUBLESHOOT или SEAUDIT из пакета SETOOLS.

Результатом раскопок должна стать информация: такому-то процессу запрещен доступ к таким-то ресурсам.

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

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

Третий путь это изменение предопределенных переменных SE booleans. Просмотреть их можно командой semanage boolean -l. Имена переменных достаточно информативны, в них мы найдем и свой случай с пользовательскими каталогами. Переменная httpd_enable_homedirs  как раз и разрешает доступ httpd к каталогам пользователей.

Переменные SE могут иметь значение on или off, просмотреть значение заданной переменной можно командой getsebool имя_переменной, установить setsebool имя_переменной on|off. По умолчанию setsebool изменяет значение переменной в памяти и после перезагрузки оно вернется к первоначальному. Чтобы измение стало постоянным используйте setsebool -P имя_переменной on|off.

Далее идут пути тернистые, от вас потребуется умение читать (и понимать:)  большие руководства на английском языке. И конечно время на опыты, 1-2 недели вполне достаточно. Не помешает напомнить, что опыты должны ставиться на тестовой, а никак не на production системе. Сам периодически нарушаю это правило и практически каждый раз об этом жалею.

Тернистые четвертый и пятый путь это изменение контекства безопасности (security context) для файлов и каталогов и редактирование политик SELinux. Тут упираешся в известное ограничение: о сложном нельзя рассказать просто. Можно конечно написать, что контекст изменяется командой chcon, а восстанавливается restorecon. Или даже дать пример chcon -R -t httpd_used_content_t public_html/ присвоения контекста каталогу для разрешения доступа к нему процесса httpd.

Но методологией это не назовешь.

Потому, решение принимается такое, оставляю статью как она есть. Если тематика окажется востребованной напишу продолжение, где и раскрою добытые бессоными ночами сведения.