SELinux bloqueando o procmail de executar o dspam, mas nenhuma mensagem AVC

Question

Eu tenho um sistema CentOS 7 no qual uso o postfix como MTA. Certos usuários usam o procmail .forwardem seus diretórios pessoais:

# cat .forward
"|exec /usr/bin/procmail -f- || exit 75"

Neste caso, estou tendo dificuldade em descobrir por que o SELinux não permitirá que o procmail execute o dspam de .procmailrc:

:0fw: dspam.lock
| /usr/bin/dspam --client --stdout --deliver=spam,innocent

No log do procmail eu recebo:

procmail: Locking "dspam.lock"
procmail: Executing "/usr/bin/dspam,--client,--stdout,--deliver=spam,innocent"
/bin/sh: /usr/bin/dspam: Permission denied
procmail: Program failure (126) of "/usr/bin/dspam"
procmail: Rescue of unfiltered data succeeded
procmail: Unlocking "dspam.lock"

No entanto, se eu definir o SELinux para o modo permissivo, ele funcionará bem.

O problema é que ele não registra nenhuma mensagem AVC sobre o que está sendo negado. Quando eu estava configurando as coisas pela primeira vez, encontrei algumas lacunas audit2whye ausearchas corrigi. Agora não recebo nada, embora seja claramente o SELinux que o está impedindo de funcionar.

Editar: aqui está o binário dspam:

# ls -lZ /usr/bin/dspam
-r-x--s--x. dspam mail system_u:object_r:dspam_exec_t:s0 /usr/bin/dspam

Answer 1

Estou tendo um problema muito semelhante. No meu caso, o selinux está impedindo silenciosamente a execução do código na minha pasta .procmailbin (já defini o contexto padrão para .procmailbin como procmail_exec_t).

Ainda não resolvi o problema, mas acredito que o caminho para a resposta é instruir o selinux a reportartodosnegações, o que acontecenãofaça por padrão.

Para ativar o relatório completo de todas as negações, use o seguinte:

semodule --disable_dontaudit --build

Revise audit.log e use o sealert conforme apropriado para determinar o que está acontecendo.

Então, para retornar as coisas ao normal quando terminar, use:

semodule --build

Boa sorte! No meu caso estou a ponto de o sealert me mostrar esta informação que não aparecia antes:

SELinux is preventing sh from search access on the directory /home/chris/.procmailbin.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that sh should be allowed search access on the .procmailbin 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:
# ausearch -c 'sh' --raw | audit2allow -M my-sh
# semodule -X 300 -i my-sh.pp

... mas ainda preciso revisar se esse é o problema real e qual é a melhor solução.

Atualização: Acontece que isso resolveu o problema para mim.

Aqui está o conteúdo do módulo personalizado que construí:

# more procmailbin-sh-search.te

module my-sh 1.0;

require {
        type dmesg_t;
        type procmail_t;
        type procmail_exec_t;
        type abrt_t;
        class dir search;
        class process noatsecure;
}

#============= abrt_t ==============
allow abrt_t dmesg_t:process noatsecure;

#============= procmail_t ==============
allow procmail_t procmail_exec_t:dir search;

Parece-me que esse deveria ser o comportamento padrão, então acho que vou ver se consigo descobrir para quem relatar esse "bug".

Answer 2

Então, depois de analisar a resposta de Chris Bennett, usei semodule --disable_dontaudite consegui descobrir o que precisava. Aqui está o que fiz para fazer o postfix + procmail + dspam funcionar:

require {
    type dspam_rw_content_t;
    type dspam_t;
    type dspam_exec_t;
    type procmail_t;
    class dir { open read write getattr add_name search };
    class file { append getattr lock open read write setgid };
    class unix_stream_socket connectto;
}

#============= dspam_t ==============
allow dspam_t dspam_rw_content_t:dir { open read write getattr add_name search };
allow dspam_t dspam_rw_content_t:file { append getattr lock open write };

#============= procmail_t ==============
allow procmail_t dspam_exec_t:file { open read setgid };
allow procmail_t dspam_t:unix_stream_socket connectto;