SELinux vs AppArmor: Comparação para servidores Linux
15 min de leitura - 21 de maio de 2026

Comparação entre SELinux e AppArmor para segurança de servidores Linux: Saiba como funciona cada estrutura MAC, as principais diferenças e qual escolher para a sua configuração de alojamento.
SELinux vs AppArmor: Qual a estrutura MAC mais adequada para o seu servidor?
Tanto o SELinux como o AppArmor aplicam o Controlo de Acesso Obrigatório (MAC) no Linux, restringindo o que os processos podem fazer, mesmo que obtenham privilégios de root. A diferença está na forma como o fazem. O SELinux atribui rótulos persistentes a todos os ficheiros e processos. O AppArmor, por sua vez, utiliza regras de caminho de ficheiros. Essa escolha de design determina tudo o resto: complexidade, nível de segurança e qual a distribuição que inclui qual a ferramenta por predefinição.
Como funciona o SELinux
O SELinux foi originalmente desenvolvido pela NSA e vem instalado por predefinição no RHEL, CentOS, Fedora e Rocky Linux. Ele atribui a cada objeto no sistema, incluindo ficheiros, processos, portas e sockets, um contexto de segurança no formato user:role:type:level. O type campo realiza a maior parte do trabalho pesado através de um mecanismo chamado Type Enforcement (TE).
Por exemplo, o servidor web Apache é executado como httpd_t. Os ficheiros de conteúdo web têm um tipo diferente. Se nenhuma regra de política permitir explicitamente httpd_t o acesso a esse tipo de conteúdo, o pedido é recusado. Este é um modelo de recusa por predefinição. Nada é permitido, a menos que uma regra indique o contrário.
O SELinux também suporta Segurança Multinível (MLS) e Segurança Multicategoria (MCS), que classificam os dados por nível de sensibilidade e restringem o acesso em conformidade. O MCS é o que confere ao SELinux o seu forte isolamento de contentores, mantendo os contentores separados uns dos outros e do anfitrião. Isto é importante em ambientes Kubernetes e OpenShift, onde os pods partilham um nó.
A desvantagem é a complexidade. O SELinux tem uma curva de aprendizagem íngreme. Resolver problemas de recusa de acesso implica ler registos de auditoria, compreender contextos de segurança e, por vezes, gerar módulos de políticas personalizados com audit2allow. Para equipas sem pessoal de segurança dedicado, essa sobrecarga é real.
Como funciona o AppArmor
O AppArmor adota uma abordagem diferente. Em vez de rotular objetos, atribui perfis de segurança às aplicações com base nos seus caminhos de ficheiros. Um perfil para /usr/sbin/nginx define quais diretórios o Nginx pode ler, a quais portas pode ligar-se e de que capacidades necessita. Os perfis são ficheiros de texto simples armazenados em /etc/apparmor.d/.
O AppArmor é a estrutura MAC padrão no Ubuntu, Debian e SUSE. Faz parte do kernel Linux desde a versão 2.6.36. As aplicações sem um perfil recorrem às permissões DAC padrão do Linux.
O AppArmor funciona em dois modos por perfil: Enforce (bloqueia e regista violações) e Complain (regista violações sem bloquear). Isto torna prático implementar novos perfis gradualmente. Comece no modo Complain, analise os registos, torne o perfil mais restritivo e, em seguida, mude para o modo Enforce.
Ferramentas como aa-genprof e aa-logprof ajudam a criar perfis de forma interativa, observando o que um aplicativo faz e gerando regras a partir do seu comportamento. Em comparação com os módulos de política do SELinux, a sintaxe é muito mais fácil de ler e editar manualmente.
A desvantagem é que as regras baseadas em caminho não acompanham os ficheiros quando estes são movidos. Um link físico ou uma montagem de ligação pode, em teoria, contornar uma restrição baseada em caminho. O AppArmor também não tem suporte nativo para MLS/MCS, pelo que pode isolar os contentores do anfitrião, mas não uns dos outros, como o SELinux faz.
Comparação lado a lado
| Funcionalidade | SELinux | AppArmor |
|---|---|---|
| Modelo de controlo de acesso | Baseado em rótulos (contextos de segurança) | Baseado em caminho (localizações no sistema de ficheiros) |
| Posição padrão | Negar tudo | Permitir tudo (restrições por perfil) |
| Movimentação de ficheiros | As etiquetas seguem o ficheiro | Segurança vinculada ao caminho |
| Suporte a MLS/MCS | Sim | Não |
| Isolamento de contentores | Container-para-container e container-para-host | Apenas de contentor para anfitrião |
| Formato da política | Módulos binários compilados | Ficheiros de texto legíveis por humanos |
| Distribuições padrão | RHEL, Fedora, CentOS, Rocky Linux | Ubuntu, Debian, SUSE |
| Curva de aprendizagem | Íngreme | Moderada |
Configuração Básica
SELinux
Verifique o estado atual:
sestatus
getenforceInicie no modo Permissive para registar violações sem bloquear nada:
setenforce 0Utilize a política «targeted» para a maioria dos servidores. Esta restringe serviços de alto risco, como servidores web e bases de dados, deixando tudo o resto sem restrições. Torne-a permanente em /etc/selinux/config:
SELINUX=enforcing
SELINUXTYPE=targetedInspecione os contextos de segurança em ficheiros e processos:
ls -Z /var/www/html
ps -eZ | grep httpdSe um serviço utilizar uma porta não padrão, atualize a política:
semanage port -a -t ssh_port_t -p tcp 9999Para aplicações personalizadas que geram recusas de acesso, crie um módulo de política a partir do registo de auditoria:
ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.ppAppArmor
Verifique quais os perfis que estão carregados:
sudo aa-statusInstale o pacote de utilitários se precisar de ferramentas de gestão de perfis:
sudo apt install apparmor-utilsGere um perfil de forma interativa enquanto a aplicação está em execução:
sudo aa-genprof /path/to/binaryAperfeiçoe o perfil verificando os registos em busca de violações:
sudo aa-logprofAlterne um perfil entre modos:
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginxQual deve usar?
A resposta prática para a maioria dos administradores: use o que vier com a sua distribuição. RHEL, CentOS, Fedora e Rocky Linux vêm com SELinux. Ubuntu, Debian e SUSE vêm com AppArmor. Ambas as estruturas têm ferramentas e políticas maduras para as suas plataformas nativas. Mudar para a opção não padrão em qualquer distribuição acrescenta trabalho e reduz o apoio da comunidade.
Para além disso, deixe que sejam os seus requisitos a decidir:
- Escolha o SELinux se precisar de conformidade com PCI DSS, HIPAA ou DISA-STIG. Se executar cargas de trabalho de contentores multi-tenant no Kubernetes ou OpenShift. Se precisar de isolamento entre contentores em hosts partilhados. Se o seu ambiente lida com dados classificados ou de sensibilidade elevada.
- Escolha o AppArmor se executar o Ubuntu ou o Debian e pretender proteção MAC sem uma curva de aprendizagem acentuada. Se a sua configuração for um servidor único ou um pequeno cluster a executar serviços web padrão. Se a implementação rápida for mais importante do que o controlo granular ao nível das etiquetas.
Ambas as estruturas acrescentam uma sobrecarga mínima de tempo de execução. O SELinux armazena em cache as decisões de acesso no seu Access Vector Cache. O carregamento de políticas do AppArmor pode acrescentar um pequeno atraso no arranque, mas tem um impacto insignificante durante a execução. Para a maioria das cargas de trabalho de alojamento, nenhuma delas será o estrangulamento.
Se precisar de uma base de alojamento fiável com acesso root total para configurar qualquer uma das estruturas, os servidores dedicados ou VPS da FDC oferecem-lhe o controlo para configurar o SELinux ou o AppArmor da forma que o seu ambiente exigir.

Processos Zombie em Linux: Localizar, Remover, Prevenir
Saiba como identificar, remover e evitar processos zombie no Linux. Comandos, correcções de código e dicas de monitorização para administradores de servidores.
15 min de leitura - 19 de maio de 2026
Lista de verificação de endurecimento do servidor Linux
15 min de leitura - 8 de maio de 2026