SELinux sem Medo: Politicas Customizadas para Servicos Criticos

Toda vez que um servico quebra em RHEL ou Rocky, o reflexo do time de plantao e o mesmo: setenforce 0, problema resolvido, ticket fechado. Seis meses depois o cluster inteiro roda em permissive, ninguem lembra por que, e o relatorio de compliance vira ficcao cientifica. A equipe Basilisk OffSec passou os ultimos dois anos derrubando ambientes assim em red teams autorizados, e a conclusao e direta: SELinux desligado encurta o caminho de uma RCE em PHP-FPM para root em menos de 90 segundos. Este artigo nao vende magia, mostra o fluxo que usamos para entregar modulos .pp versionados em producao sem quebrar deploy.

Antes de escrever qualquer policy, voce precisa ler o que ja existe. O comando seinfo -t lista cerca de 5.000 tipos no RHEL 9 padrao, e sesearch --allow -s httpd_t mostra exatamente o que o Apache pode tocar. Comecamos toda investigacao com ausearch -m AVC -ts recent rodando em paralelo com o servico em modo permissivo TEMPORARIO, jamais o sistema inteiro. Use semanage permissive -a httpd_t para isolar somente o dominio sob investigacao. Esse padrao salvou auditorias completas que descrevemos no Hardening de Linux Servidor: CIS Benchmark Aplicado sem Quebrar Producao, onde o CIS exige enforcing global mas permite excecoes documentadas por dominio especifico.

O audit2allow e uma faca de dois gumes. Rodar ausearch -m AVC | audit2allow -M meumodulo gera um .te que compila e funciona, mas frequentemente concede permissoes absurdas tipo allow httpd_t shadow_t:file read. Nosso checklist interno exige que todo .te passe por revisao manual antes do semodule -i. Procure por regras que toquem em shadow_t, etc_t, kernel_t ou self:capability sys_admin, esses sao red flags. Em uma investigacao recente, descrita parcialmente no DFIR no Linux: Triagem ao Vivo com UAC e Velociraptor, um modulo gerado as cegas tinha aberto acesso ao /etc/sudoers e ninguem percebeu por oito meses.

Para servicos novos, preferimos escrever policy do zero com a macro language do refpolicy. Um modulo tipico tem tres arquivos: meuservico.te com as regras, meuservico.fc com file contexts e meuservico.if com interfaces para outros dominios. O make -f /usr/share/selinux/devel/Makefile gera o .pp que voce instala com semodule -i. Versionamos esses tres arquivos no git junto com Ansible, e cada PR roda checkmodule -M -m e sediff contra a baseline. Esse processo se conecta com o que mostramos no Supply Chain Security: Assinatura com Sigstore e SBOM Real em CI/CD, onde o .pp acaba assinado com Sigstore antes de chegar nos nodes.

Servicos que abrem socket em portas nao padrao sao o caso mais comum de quebra silenciosa. Postgres na 5433 por exemplo precisa de semanage port -a -t postgresql_port_t -p tcp 5433, e nao de uma nova policy. Nginx servindo arquivos fora de /var/www quer semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?" seguido de restorecon -Rv /srv/app. 80 por cento dos casos que vemos sao file context e port labeling, nao policy nova. O time que entende essa diferenca economiza horas, e o assunto aparece de novo quando discutimos pivoting interno no Nmap Avancado: Scripts NSE para Recon Interno em Lab Corporativo Simulado.

Manutencao em producao exige observabilidade. Configuramos setroubleshoot-server em modo silent enviando AVCs para o SIEM via journald, com regras Sigma especificas para denials nao esperados. Quando um deploy quebra, o alerta chega antes do usuario reclamar. Tambem rodamos sealert -a /var/log/audit/audit.log semanalmente em staging para pegar policy drift. Esse fluxo de feedback continuo e exatamente o que defendemos no Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue: red team encontra o caminho, blue team escreve a policy, e a policy entra no pipeline.

Takeaway pratico: nunca rode setenforce 0 em producao por mais de 15 minutos. Use semanage permissive -a dominio_t para isolar o problema, capture AVCs com ausearch, revise audit2allow manualmente, commite o .te no git, assine o .pp e deploye via Ansible. Se voce nao consegue justificar cada allow rule em revisao de codigo, a policy nao esta pronta. SELinux nao e obstaculo, e o ultimo perimetro depois que o atacante ja esta dentro.