Conceito e mecanismo
Permissões Unix, ACLs e SELinux são mecanismos distintos. Um AVC num path novo pode indicar labeling inadequado mesmo com bits Unix corretos. Revê o denial e o contexto esperado; associações persistentes evitam que um relabel desfaça uma correção temporária. Abrir permissões a todos não altera a política obrigatória. Em SSH, ownership e modos inseguros podem causar rejeição com StrictModes. A correção deve proteger home, .ssh e authorized_keys no âmbito relevante, mantendo o controlo em vez de o remover.
Aplicação guiada
Uma regra sudo restrita deve considerar comando, argumentos e integridade dos ficheiros executados. Permitir um script editável como root pode conceder administração geral indiretamente. Um checksum permite comparação com uma referência, mas confiança depende da origem dessa referência; ficheiro e hash controlados pelo mesmo atacante podem coincidir. Na criação de ficheiros sem ACL predefinida, umask retira bits do modo pedido, não acrescenta execução. Finalmente, permitir uma porta na firewall não inicia o serviço: confirma listener, bind e contexto de rede.
Modo pedido 0666 com umask 0027 resulta em 0640 na ausência de ACL predefinida. Documenta esta hipótese quando calculas permissões de ficheiros criados pelo batch.
Armadilhas comuns
Desativar SELinux sem diagnóstico; usar chmod 777 como reparação; confundir hash com assinatura; deixar scripts sudo editáveis.
Tópicos relacionados: Automatização repetível e resultados fiáveis · Diagnóstico de disco, CPU e memória
Uma correção segura satisfaz o acesso necessário sem criar uma concessão mais ampla.
Referência: RHEL 10: troubleshooting SELinux · XK0-006 V8