Auditoria não diz nada para fazer, mas o fantoche não funciona com o cumprimento do SELinux

Question

Estou determinado a fazer com que o meu mestre de marionetes funcione com o SELinux definido como impondo. Se eu torná-lo permissivo, corre bem.

Estou no RHEL 7, com systemd, apache2, passageiro 4 e fantoche 3.

Eu passei por alguns passes usando o log de auditoria e audit2allow, para fazer semódulos que cobrem o log de auditoria. (E é uma grande bagunça, com o passageiro correndo de um módulo do apache, como o usuário do apache, executando o código mestre de bonecos.)

Esta é uma configuração totalmente nova, então o manifesto de puppet é um nó vazio padrão, sem nada para fazer.

Se eu executar "puppet agent -t" em uma máquina remota, será bem-sucedido com setenforce 0. O log de auditoria está bem vazio. (audit2allow relata "nada para fazer").

Mas se eu transformar o setenforce 1, recebo estes:

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

Eu tentei alterar as propriedades em / etc / puppet / *, e o contexto se parece bem:

[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

Alguma sugestão de solução de problemas?

[Editar]: Informações adicionais, seguindo a sugestão de desativar "dontaudit" e repetir o exercício, as mensagens de erro foram alteradas. Meu $ ssldir é / var / lib / puppet / ssl e $ logdir é / var / log / puppet, o que torna esses erros interessantes:

puppet-master [3210]: Permissão negada - / etc / puppet / ssl

puppet-master [3210]: (/ Arquivo [/ etc / puppet / ssl] / assegurar) alteração de ausente para diretório falhou: Não foi possível definir 'diretório' para garantir: Permissão negada - / etc / puppet / ssl

puppet-master [3210]: Não foi possível preparar para a execução: Recebeu 3 falha (s) durante a inicialização: Arquivo [/ etc / puppet / ssl]: alteração de ausente para diretório falhou: não foi possível definir 'diretório' para garantir : Permissão negada - / etc / puppet / ssl; Arquivo [/ etc / puppet / manifests]: mudança de ausente para diretório falhou: Não foi possível definir 'diretório' para garantir: Permissão negada - / etc / puppet / manifests; Arquivo [/ var / lib / puppet / log]: mudança de 0755 para 0750 falha: falha ao definir o modo 755 em / var / lib / puppet / log: Permissão negada - / var / lib / puppet / log

Tudo funciona, claro, em Permissivo. : (

    

Answer 1

Para me aprofundar no problema, instalei o pacote setroubleshoot-server no meu mestre de marionetes. Em vez de colocar a máquina no modo Permissivo, deixei-a no Forçando. Então eu canalizei meu log de auditoria para sealert e obtive esta gem:

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

E, de fato, isso permite que um mestre de marionetes seja executado no modo Forçar.

Minha teoria é que, no modo Forçando, o mestre Puppet é ativado em um caminho de código diferente que aciona os alertas de acesso adicionais, não descobertos no modo Permissivo.