SELinux vs AppArmor: Comparação para servidores Linux

15 min de leitura - 21 de maio de 2026

hero section cover
Índice
  • SELinux vs AppArmor: Qual a estrutura MAC mais adequada para o seu servidor?
  • Como funciona o SELinux
  • Como funciona o AppArmor
  • Comparação lado a lado
  • Configuração Básica
  • Qual deve usar?
Partilhar

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

FuncionalidadeSELinuxAppArmor
Modelo de controlo de acessoBaseado em rótulos (contextos de segurança)Baseado em caminho (localizações no sistema de ficheiros)
Posição padrãoNegar tudoPermitir tudo (restrições por perfil)
Movimentação de ficheirosAs etiquetas seguem o ficheiroSegurança vinculada ao caminho
Suporte a MLS/MCSSimNão
Isolamento de contentoresContainer-para-container e container-para-hostApenas de contentor para anfitrião
Formato da políticaMódulos binários compiladosFicheiros de texto legíveis por humanos
Distribuições padrãoRHEL, Fedora, CentOS, Rocky LinuxUbuntu, Debian, SUSE
Curva de aprendizagemÍngremeModerada

Configuração Básica

SELinux

Verifique o estado atual:

sestatus
getenforce

Inicie no modo Permissive para registar violações sem bloquear nada:

setenforce 0

Utilize 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=targeted

Inspecione os contextos de segurança em ficheiros e processos:

ls -Z /var/www/html
ps -eZ | grep httpd

Se um serviço utilizar uma porta não padrão, atualize a política:

semanage port -a -t ssh_port_t -p tcp 9999

Para 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.pp

AppArmor

Verifique quais os perfis que estão carregados:

sudo aa-status

Instale o pacote de utilitários se precisar de ferramentas de gestão de perfis:

sudo apt install apparmor-utils

Gere um perfil de forma interativa enquanto a aplicação está em execução:

sudo aa-genprof /path/to/binary

Aperfeiçoe o perfil verificando os registos em busca de violações:

sudo aa-logprof

Alterne um perfil entre modos:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

Qual 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.

Blogue

Em destaque esta semana

Mais artigos
Processos Zombie em Linux: Localizar, Remover, Prevenir

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

Mais artigos