As duas atenuações são necessárias quando o audit2allow sugere uma regra de restorecon e uma de tipo?

Question

O SELinux é um modo permissivo para ajudar a evitar problemas operacionais durante a transição para uma nova implementação do servidor RHEL7. Embora alguns problemas do SELinux sejam razoavelmente fáceis de revisar e resolver com um pouco de confiança, acho o seguinte um pouco desconcertante.

O AVC é o seguinte:

type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket

audit2why diz:

type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket

        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

audit2allow diz:

#============= postfix_postdrop_t ==============

#!!!! The file '/var/spool/postfix/public/pickup' is mislabeled on your system. 
#!!!! Fix with $ restorecon -R -v /var/spool/postfix/public/pickup
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

O aviso parece implicar que alguma parte do problema deve ser corrigida executando algo como:

# restorecon -R -v /var/spool/postfix/public/pickup
# ls -lZ /var/spool/postfix/public/pickup
srw-rw-rw-. postfix postfix unconfined_u:object_r:postfix_public_t:s0 /var/spool/postfix/public/pickup

Os problemas de auditoria do SELinux, no entanto, não parecem mudar depois disso, então, aparentemente, há mais a ser feito. Presumivelmente, alguns dos problemas estão relacionados com a auditoria da segunda menção:

allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

Parece estranho que um problema do SELinux com um serviço bem estabelecido como o postfix deva requerer intervenção do administrador.

Provavelmente, um caminho para resolver o problema pode ser o seguinte:

# echo 'type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
  | audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp

Este é realmente um problema de rotulagem, ou é apenas um efeito colateral do "permitir" em falta, e alguém pode comentar se essa é uma alteração esperada legítima que um administrador deve fazer para obter um postfix instalação funcionando sem problemas no SELinux?

Por favor, não sugira desligar o SELinux. Certamente isso é uma opção, mas eu prefiro aprender a deixá-lo e aprender a discernir o curso adequado de ação para fazê-lo quando surgem problemas dessa natureza.

NOTA: Os comandos audit2allow -M .. e semanage -i acima mencionados resolvem os problemas do SELinux sem reclassificar, mas ainda não está claro se uma reclassificação pode ter evitado a necessidade de criar a política. Ainda não está claro se a resolução do problema é esperada e / ou normal.

#============= postfix_postdrop_t ==============

#!!!! This avc is allowed in the current policy
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

    

Answer 1

Na verdade, como restorecon foi usado, esses comandos não são necessários para resolver problemas do SELinux:

# echo 'type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
  | audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp

Aqui está o porquê, e esperamos que a explicação possa ajudar quando alguém está tentando resolver os problemas de auditoria do SELinux.

• Tome cuidado para observar os tipos antes das etapas de mitigação. Neste caso:

  unix_stream_socket

  É lamentável que ls -lZ /var/spool/postfix/public/pickup não tenha sido executado antes que o comando restorecon fosse executado, já que isso ajudaria na compreensão.

  TIP : observe os contextos do SELinux antes de fazer alterações.

• Observe o tipo do SELinux depois que restorecon -R -v /var/spool/postfix/public/pickup foi executado:

  postfix_public_t

  É importante observar que ocorreu uma alteração de tipo.

  TIP : Quando o comando restorecon sugerido e uma única regra allow estão listados, não é improvável que as sugestões de mitigação sejam soluções alternativas (nem ambas, podem resolver o problema questão).

• Observe que a saída audit2allow foi alterada de tal forma que o comando restorecon sugerido não está mais presente.

  Quando o audit2allow output tiver um comando restorecon e apenas um rule , após uma tentativa de atenuação usando restorecon , é muito provável que o problema seja resolvido. A chave aqui é perceber que o rule exibido para o AVC não é mais relevante, porque não há mais motivo para uma regra referente a um tipo que não está mais em uso.

  Por exemplo, neste caso específico, não há razão para que postfix_postdrop_t tenha acesso a um unix_stream_socket quando esse soquete agora tiver um início de postfix_public_t .

Em qualquer outro caso como este, é importante lembrar que o próprio AVC é para um evento histórico. Como o AVC é para um evento histórico, deve-se ter em mente que soluções alternativas para problemas antigos podem não ser necessárias se os detalhes na solução alternativa não forem mais idênticos ao estado do sistema no momento em que o evento ocorreu. Em outras palavras, depois que o comando restorecon foi usado, não é necessário esperar mensagens "permitido na política atual" quando uma sugestão restorecon não estiver mais presente.

Caso você ainda esteja se perguntando sobre a sabedoria de não usar ambas as atenuações, acalme-se no fato de que, se ambas as mitigações forem realmente necessárias, um futuro evento de auditoria ocorrerá.

Na verdade, existe um benefício colateral para NÃO usar várias atenuações. Lembre-se, o objetivo do SELinux é restringir os processos para acessar as coisas que eles realmente precisam. Se forem feitas alterações de imposição de tipo desnecessárias, o executável postfix_postdrop_t não estará mais impedido de acessar outros recursos unix_stream_socket que não têm nada a ver com a execução de postfix e uma restrição legítima de tempo de execução em postfix será subvertida .

Um título mais adequado para essa pergunta pode ser: " As duas atenuações são necessárias quando o audit2allow sugere a restauração e a alteração de uma regra? "