Поговорим с SELinux.

Опубликовано

Если мы установили, что защита 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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *