Я полон решимости запустить моего мастера марионеток с SELinux, установленным на принудительное исполнение. Если я сделаю это допустимым, все будет нормально.
Я использую RHEL 7 с systemd, apache2, пассажиром 4 и марионеткой 3.
Я прошел через пару проходов, используя журнал аудита и audit2allow, чтобы создать модули, покрывающие журнал аудита. (И это большой беспорядок, когда пассажир запускается из модуля apache в качестве пользователя apache, выполняющего мастер-код марионетки.)
Это совершенно новая конфигурация, поэтому манифест марионетки - это пустой узел по умолчанию, которому нечего делать.
Если я запускаю "puppet agent -t" на удаленном компьютере, он преуспевает с setenforce 0. Журнал аудита довольно пуст. (audit2allow сообщает «нечего делать».)
Но если я включу setenforce 1, я получу следующее:
Aug 20 23:14:28 puppet002 puppet-master[1544]: Permission denied - /etc/puppet/auth.conf
Aug 20 23:14:29 puppet002 puppet-master[1544]: Permission denied - /etc/puppet/manifests/site.pp on node agentserver.example.com
Я пробовал менять владельцев на / etc / puppet / *, и контекст se выглядит нормально:
[root@puppet002 log]# cd /etc/puppet
[root@puppet002 puppet]# ls -lZ
-rw-r--r--. apache apache system_u:object_r:puppet_etc_t:s0 auth.conf
-rw-r--r--. apache apache system_u:object_r:puppet_etc_t:s0 fileserver.conf
drwxr-xr-x. apache apache system_u:object_r:puppet_etc_t:s0 manifests
drwxr-xr-x. apache apache system_u:object_r:puppet_etc_t:s0 modules
-rw-r--r--. apache apache system_u:object_r:puppet_etc_t:s0 puppet.conf
Есть предложения по устранению неполадок?
[Edit]: Дополнительная информация, после предложения отключить «dontaudit» и повторить упражнение, сообщения об ошибках изменились. Мой $ ssldir - это / var / lib / puppet / ssl, а $ logdir - это / var / log / puppet, что делает эти ошибки интересными:
puppet-master [3210]: в доступе отказано - / etc / puppet / ssl
puppet-master [3210]: (/ File [/ etc / puppet / ssl] / sure) произошла ошибка при переходе с «absent / puppet / ssl» в каталог: не удалось установить «каталог» для обеспечения: разрешение запрещено - / etc / puppet / ssl
puppet-master [3210]: Не удалось подготовиться к выполнению: Произошло 3 сбоя при инициализации: Файл [/ etc / puppet / ssl]: сбой при изменении с отсутствующего на каталог: Не удалось установить «каталог» при гарантии: В доступе отказано - / etc / puppet / ssl; Файл [/ etc / puppet / manifestests]: не удалось изменить «каталог» на «каталог»: не удалось установить «каталог» при гарантии: в доступе отказано - / etc / puppet / manifest; Файл [/ var / lib / puppet / log]: изменение с 0755 на 0750 не удалось: не удалось установить режим 755 в / var / lib / puppet / log: в доступе отказано - / var / lib / puppet / log
Все работает конечно в Permissive. :(
Чтобы глубже разобраться в проблеме, я установил setroubleshoot-server пакет на моего кукловода. Вместо того, чтобы переводить машину в разрешающий режим, я оставил ее в принудительном режиме. Затем я отправил свой журнал аудита в sealert и получил этот драгоценный камень:
found 3 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------
SELinux is preventing /usr/bin/ruby from search access on the directory .
***** Plugin catchall (100. confidence) suggests **************************
If you believe that ruby should be allowed search access on the directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep ruby /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
И действительно, это позволяет мастеру марионетки успешно работать в принудительном режиме.
Моя теория состоит в том, что в принудительном режиме мастер марионетки переключается на другой путь кода, который запускает дополнительные предупреждения доступа, не обнаруженные в разрешающем режиме.