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 comandorestorecon
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 regraallow
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 comandorestorecon
sugerido não está mais presente.Quando o
audit2allow
output tiver um comandorestorecon
e apenas umrule
, após uma tentativa de atenuação usandorestorecon
, é muito provável que o problema seja resolvido. A chave aqui é perceber que orule
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 umunix_stream_socket
quando esse soquete agora tiver um início depostfix_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? "