Por que o audit2why não tem nada para fazer?

Question

Eu sei que tenho um problema com o SElinux. Então eu estou seguindo um tutorial que me ajudará a entender a natureza dos problemas de acesso a arquivos que estou tendo. Eu ainda posso ter o reforçamento do SElinux como se fosse apenas desativá-lo.

Basicamente, eu configurei o SElinux como modo permissivo, para teste e executei uma ação de arquivo que falharia enquanto estava sendo aplicada. Dessa forma, vou ver como é a mensagem no log. Tal linha se parece com isso:

type=USER_CMD msg=audit(1452912989.069:324790): pid=66581 uid=1001 auid=1001 ses=1352 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/srv/dpca/www" cmd=7461696C202F7661722F6C6F672F61756469742F61756469742E6C6F67 terminal=pts/0 res=success'

Agora, como sou realmente novo para isso, consultei o tutorial e como ele fala sobre a obtenção de audit2why para definir isso para mim.

[matt@localhost www]$ sudo grep 1452912989.069:324790 /var/log/audit/audit.log | audit2why
Nothing to do

O grep retorna o texto correto. No entanto, audit2why parece estar retornando "Nothing to do".

Existe algo fundamental que estou fazendo errado? Fim do dia Estou tentando descobrir qual contexto atribuir a alguns diretórios do NGINX. Eu tenho certeza que posso apenas procurá-los, mas eu também queria entender o que eu estou fazendo, como supostamente apenas executando comandos que vejo na internet.

Caso você esteja curioso, este é um pequeno trecho do meu contexto de diretório raiz da web

drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 administrator
drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 bin
drwxr-xr-x. nginx nginx unconfined_u:object_r:httpd_sys_content_t:s0 cache

    

Answer 1

Observação: ainda estou interessado em uma resposta ao meu problema, mas queria postar uma solução alternativa que estou usando e que fornece informações igualmente úteis se audit2why estava trabalhando como eu teria esperado.

No Howto for SELinux no CentOS.org , há uma seção de solução de problemas. A seguir, há conversas sobre como usar sealert para fornecer informações legíveis a humanos a partir do log "/var/log/audit/audit.log". Então simplesmente rodando

sudo sealert -a /var/log/audit/audit.log > ~/logfile.txt 

me permitiu ler as informações que eu queria e obter sugestões sobre o contexto de segurança adequado para meus diretórios da web.

SELinux is preventing /usr/sbin/php-fpm from write access on the directory /srv/dpca/www/images.

*****  Plugin httpd_write_content (92.2 confidence) suggests   ***************

If you want to allow php-fpm to have write access on the images directory
Then you need to change the label on '/srv/dpca/www/images'
Do
# semanage fcontext -a -t httpd_sys_rw_content_t '/srv/dpca/www/images'
# restorecon -v '/srv/dpca/www/images'

Novamente, se alguém souber da minha pergunta original sobre audit2why , ainda gostaria de saber.