Если мы установили, что защита SELinux не пропускает наше действие, самое время с ней пообщаться. Вводим в терминале
# sealert -a /var/log/audit/audit.log
и получаем рассказ SELinux про всё тревоги с момента последнего запроса. Многовато? Удаляем сообщения.
# cat /dev/null > /var/log/audit/audit.log
, проверяем
# sealert -a /var/log/audit/audit.log
0% donefound 0 alerts in /var/log/audit/audit.log
, ну вот, теперь проще.
Повторяем действие блокированное SELinux и смотрим.
# sealert -a /var/log/audit/audit.log
Конечно надо понимать что мы делаем, поскольку не все тревоги напрямую связаны с действием.
В моём конкретном случае CMS работая на локальном HTTPd не могли производить запись в свои директории, и желания Апача поискать не знаю что по разным папкам меня мало интересовало. SELinux предложил несколько вариантов изменения правил, вариант с правами Апача на запись нужных папок меня устроил.
Вводим
# semanage fcontext -a -t httpd_sys_rw_content_t ‘/путь к папке назначения’
вводим
# restorecon -v ‘/путь к папке назначения’
обычно /var/www/ а дальше у каждого своё. Повторяем очистку лога, запрос тревог и назначение прав на директории, если SELinux продолжает блокировать действие.
На уровне конечных директорий для файлов создаём уже локальные правила.
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp