AppArmor ou SELinux: qual sistema MAC usar no Linux?

Quando endurece uma máquina Linux, mais cedo ou mais tarde chega a uma bifurcação: AppArmor ou SELinux. Ambos são sistemas de Controlo de Acesso Obrigatório (MAC) integrados no núcleo do Linux através do mesmo framework LSM (Linux Security Modules). Ambos confinam um processo comprometido para que uma exploração não possa alcançar livremente o resto do sistema. Mas adotam abordagens muito diferentes, e a escolha certa depende menos de qual é «mais poderoso» do que daquilo que executa, da distribuição que usa e de quanto trabalho de política está disposto a assumir.

Este guia compara-os por concepção, por custo de manutenção diário e por modelo de ameaça, para que decida em vez de adivinhar.

O que o Controlo de Acesso Obrigatório faz realmente

As permissões clássicas do Linux são discricionárias: o proprietário de um ficheiro decide quem o pode ler ou escrever, e um processo é executado com todas as permissões do utilizador que o iniciou. Se esse processo for comprometido, o atacante herda essas permissões: os seus ficheiros, a sua rede, a sua pasta pessoal.

O Controlo de Acesso Obrigatório acrescenta uma segunda camada que o utilizador não pode contornar. Uma política central, aplicada pelo núcleo, decide o que cada processo pode fazer independentemente da propriedade do ficheiro. A um servidor web confinado por MAC pode impor-se que leia apenas a sua própria raiz de documentos e escute na porta 443; e mesmo que um atacante o assuma, o núcleo continua a recusar tudo o que esteja fora desse envelope.

AppArmor e SELinux cumprem ambos essa função. A diferença está em como identificam aquilo que um processo está autorizado a tocar.

A diferença essencial de concepção: caminhos contra etiquetas

Esta única distinção explica quase todos os compromissos práticos entre os dois.

O AppArmor baseia-se em caminhos. Um perfil indica os caminhos reais de ficheiros a que um programa pode aceder. Uma regra como /etc/nginx/** r significa «o nginx pode ler qualquer coisa sob /etc/nginx». Isto corresponde diretamente à forma como os administradores já pensam num sistema, tornando os perfis legíveis e rápidos de escrever.

O SELinux baseia-se em etiquetas. Cada ficheiro, processo, socket e porta transporta um contexto de segurança (uma etiqueta) como httpd_sys_content_t. As regras descrevem que etiquetas podem interagir entre si, e não que caminhos. O caminho /var/www/html/index.html é irrelevante para o SELinux; o que conta é a etiqueta que lhe está associada.

A consequência: se mover um ficheiro no AppArmor, a regra continua a aplicar-se enquanto o novo caminho estiver coberto. No SELinux, um ficheiro movido pode manter ou perder a sua etiqueta consoante o método usado (cp e mv comportam-se de forma diferente), a fonte de confusão mais comum do tipo «funcionava até eu copiar o ficheiro». Em contrapartida, uma política baseada em etiquetas é mais difícil de enganar: um atacante não pode contornar uma regra alcançando os mesmos dados através de uma ligação simbólica ou de um caminho alternativo, porque a etiqueta viaja com o objeto.

Granularidade e nível de garantia

O SELinux é o mais granular dos dois. Como cada objeto é etiquetado, a política pode exprimir controlos fora do alcance do AppArmor: segurança multinível, aplicação de tipos sobre centenas de domínios e restrições que separam, por exemplo, duas aplicações web que residem ambas sob /var/www mas que nunca deveriam ler os dados uma da outra. Por isso o SELinux é a predefinição em ambientes com requisitos de segurança formais (RHEL, Fedora, implementações de matriz governamental) e foi originalmente desenvolvido com a Agência de Segurança Nacional dos Estados Unidos.

O AppArmor é deliberadamente mais grosseiro. Não consegue exprimir tudo o que o SELinux exprime, mas para o objetivo comum – confinar alguns serviços expostos à rede e navegadores para que uma única exploração não possa saltar adiante – esse teto raramente importa. A maioria dos modelos de ameaça de computadores de secretária e de pequenos servidores fica plenamente coberta pela expressividade do AppArmor.

Uma boa forma de o enquadrar: o SELinux oferece um teto mais alto; o AppArmor oferece um piso de esforço mais baixo. Qual vence depende inteiramente de saber se precisa realmente desse teto.

O custo de manutenção no mundo real

É aqui que a escolha costuma decidir-se.

Com o AppArmor, os perfis são breves ficheiros de texto que pode ler e editar à mão. As distribuições que o adotam por predefinição (Ubuntu, Debian, openSUSE) incluem perfis já prontos, e pode gerar novos de forma interativa:

# Ver que perfis estão carregados e em que modo
sudo aa-status

# Gerar um perfil para uma aplicação observando-a em execução
sudo aa-genprof /usr/bin/myapp

# Colocar um perfil em modo de aplicação
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

Um modo «complain» regista as violações sem as bloquear, o que permite desenvolver um perfil num sistema em produção e apertá-lo assim que as necessidades legítimas da aplicação são conhecidas.

Com o SELinux, a política é vasta e quase nunca a escreve de raiz: ajusta valores booleanos e reetiqueta ficheiros. O ponto de atrito é diagnosticar as recusas. O reflexo errado é executar setenforce 0 para o desativar; o certo é ler o registo de auditoria:

# Verificar o modo atual
getenforce

# Examinar as recusas recentes e obter uma política sugerida
sudo ausearch -m avc -ts recent | audit2allow -a

# Repor as etiquetas corretas num caminho
sudo restorecon -Rv /var/www/html

O audit2allow propõe um módulo de política que permitiria a ação recusada; revê-o antes de o aplicar para perceber porquê a recusa ocorreu, em vez de permitir em bloco. Este fluxo é poderoso mas tem uma curva de aprendizagem real, e é a principal razão pela qual os administradores desativam o SELinux em vez de o aprenderem, o que elimina por completo a proteção.

Siga a predefinição da sua distribuição

Na prática, a recomendação mais sólida é também a mais simples: use o sistema MAC que a sua distribuição inclui e mantém.

Ir contra a predefinição significa executar uma configuração não suportada: os perfis AppArmor para os pacotes do Fedora não são mantidos, e a política SELinux para a disposição de pacotes do Ubuntu é incompleta. Herda um encargo de manutenção que a distribuição não o ajudará a suportar. Numa máquina Fedora ou RHEL, deixe o SELinux em modo Enforcing e aprenda o audit2allow. No Ubuntu ou Debian, mantenha o AppArmor ativado e garanta que o navegador e os serviços de rede correm com perfis em modo de aplicação.

É o mesmo princípio por trás da escolha de uma distribuição Linux segura: a proteção que é de facto mantida vale mais do que a proteção teoricamente mais forte mas não suportada no seu sistema.

O lugar do MAC numa defesa em camadas

Nem o AppArmor nem o SELinux são uma estratégia de segurança completa. O MAC confina processos já em execução; não faz nada contra código não fiável que escolha executar, nem para isolar cargas de trabalho inteiras umas das outras. Para isolar aplicações individuais do ambiente de trabalho, as ferramentas de sandbox como o Firejail e o bubblewrap trabalham ao lado do MAC em vez de o substituírem. Para um endurecimento de sistema mais amplo – parâmetros do núcleo, sysctl, arranque verificado – o MAC é apenas uma camada no quadro mais geral do endurecimento do Linux, e insere-se na comparação mais ampla entre os modelos de segurança do Linux e do Windows.

A conclusão é que a pergunta AppArmor-ou-SELinux é real mas restrita. Escolha aquele que a sua distribuição mantém, deixe-o em modo de aplicação e dedique o resto do seu esforço às camadas acima e abaixo dele.

Perguntas frequentes

O SELinux é mais seguro do que o AppArmor? O SELinux pode exprimir uma política mais rigorosa e fina, por isso em termos absolutos o seu teto é mais alto. Mas a segurança nasce de uma política realmente aplicada e mantida. Um sistema AppArmor deixado em modo de aplicação protege-o mais do que um sistema SELinux que alguém desativou porque as recusas eram confusas.

Posso usar ambos ao mesmo tempo? Não. O AppArmor e o SELinux são ambos LSM «principais» e o núcleo carrega apenas um como sistema MAC primário. Escolhe um por máquina: na prática, o que a sua distribuição predefine.

Devo alguma vez desativá-los? Quase nunca. Desativar o MAC retira uma camada que limita a extensão dos danos de um serviço comprometido. Perante uma recusa, diagnostique-a (audit2allow para o SELinux, modo complain para o AppArmor) em vez de desligar tudo.

Qual é mais fácil para um principiante? O AppArmor. Os seus perfis por caminhos leem-se como o sistema de ficheiros que já compreende, e o Ubuntu e o Debian incluem perfis funcionais de origem. O SELinux recompensa o tempo investido a aprendê-lo, mas esse tempo é real.