SELinux em produção — o workflow que de fato funciona, e os AVC denials que continuamos encontrando

«Setenforce 0» não é uma estratégia de segurança. É, no entanto, o «fix» mais comum que vemos para denials de SELinux em hosts de cliente. O raciocínio é sempre o mesmo: uma aplicação quebrou, a mensagem de erro mencionou SELinux, alguém desabilitou o SELinux, a aplicação voltou a funcionar, e ninguém voltou.

Este é o workflow de SELinux que usamos em cada host RHEL gerenciado. A premissa: SELinux fica em modo enforcing. A policy customizada é pequena e versionada. O debug segue um conjunto conhecido de passos, em ordem.

Debug de um AVC denial

# Passo 1 — o que foi negado?
ausearch -m AVC -ts recent | grep denied
 
# Passo 2 — pegar a explicação legível por humano
sealert -a /var/log/audit/audit.log
 
# Passo 3 — gerar um módulo de policy candidato (revisar antes de aplicar)
ausearch -m AVC -ts recent | audit2allow -M my_app_policy
# LEIA O ARQUIVO my_app_policy.te. Não aplique sem mais.
 
# Passo 4 — se a policy for razoável, instalá-la
semodule -i my_app_policy.pp

O passo 3 é o que a maioria dos times pula. O audit2allow é feliz em gerar uma policy ampla demais. Revise o arquivo .te. Apare o que não deveria estar ali. Depois aplique.

O artigo completo cobre:

• O workflow de debug em cinco passos em ordem (e o que fazer se o passo 4 não bastar)
• A policy targeted — o que cobre e onde estendê-la
• Padrões de semanage fcontext para caminhos de arquivo não padrão
• Booleans do SELinux (getsebool -a | grep <service>) para os fixes fáceis
• Contextos de arquivo que sobrevivem a um restorecon
• A lista de booleans monitorados nos quais alertamos (desligar um é bandeira vermelha)

Rodamos esse workflow em cada host RHEL gerenciado. SELinux fica ligado.