Início / unix / Perguntas / 460924
Accepted
kbulgrien
Asked: 2018-08-07 16:17:12 +0800 CST

Ambas as mitigações são necessárias quando audit2allow sugere tanto restorecon quanto uma regra de imposição de tipo?

  • 772

O SELinux é um modo permissivo para ajudar a evitar problemas operacionais durante uma transição para uma nova implantação de servidor RHEL7. Embora alguns problemas do SELinux sejam bastante fáceis de revisar e resolver com um mínimo de confiança, acho o seguinte um tanto 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 disse:

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 disse:

#============= 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 registrados na auditoria do SELinux, no entanto, não parecem mudar depois que isso é feito, então, aparentemente, há mais a ser feito. Presumivelmente, alguns dos problemas estão relacionados à menção audit2allow de:

allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

Parece estranho que um problema do SELinux com um serviço muito bem estabelecido como o postfix exija a intervenção do administrador.

Provavelmente, um caminho para resolver o problema pode ser ao longo das linhas de:

# 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

Dito isso, parece imprudente simplesmente fazer coisas para desaparecer os problemas de auditoria sem uma melhor compreensão de por que tal mudança deve ser considerada legítima.

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

Por favor, não sugira desligar o SELinux. Certamente essa é uma opção, mas prefiro aprender como deixá-la ligada e aprender a discernir o curso de ação adequado para fazê-lo quando surgirem questões dessa natureza.

NOTA: Os comandos audit2allow -M ..e acima mencionados semanage -iresolvem problemas do SELinux sem reetiquetagem, mas ainda não está claro se uma reetiquetagem pode ter evitado a necessidade de criar a política. Ainda não está claro se resolver o problema dessa maneira é esperado e/ou normal.

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

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

1 respostas

  1. Best Answer

    Na verdade, desde que restoreconfoi 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 esperançosamente uma explicação que pode ajudar quando alguém está tentando resolver problemas de auditoria do SELinux.

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

      unix_stream_socket

      É lamentável que ls -lZ /var/spool/postfix/public/pickupnão tenha sido executado antes que o restoreconcomando fosse executado, pois isso teria ajudado a obter entendimento.

      DICA : Observe os contextos do SELinux antes de fazer alterações.

    • Observe o tipo SELinux depois de restorecon -R -v /var/spool/postfix/public/pickupexecutado:

      postfix_public_t

      É importante notar que ocorreu uma mudança de tipo.

      DICArestorecon : Quando um comando sugerido e uma única allowregra são listados, não é improvável que as sugestões de mitigação sejam soluções alternativas (ou ambas, não as duas, podem resolver o problema).

    • Observe que a audit2allowsaída mudou de tal forma que o comando sugerido restoreconnão está mais presente.

      Quando audit2allowa saída tem um restoreconcomando e apenas uma rulealteração, após uma tentativa de mitigação usando restorecon, muito provavelmente o problema está resolvido. A chave aqui é perceber que o ruleexibido 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 postfix_postdrop_treceber acesso a um unix_stream_socketquando esse soquete agora tem um topo 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 da solução alternativa não forem mais idênticos ao estado do sistema no momento em que o evento ocorreu. Em outras palavras, uma vez que o restoreconcomando foi usado, não é necessário esperar mensagens "permitido na política atual" quando uma restoreconsugestão não estiver mais presente.

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

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

    Um título mais apropriado para essa pergunta pode ser: " As duas mitigações são necessárias quando audit2allow sugere tanto restorecon quanto uma alteração de regra? "

    • 0

relate perguntas