O AppArmor (Application Armor) é um módulo de segurança do kernel Linux (LSM — Linux Security Module) que implementa controle de acesso obrigatório (MAC) baseado em perfis por aplicação. Em vez de proteger o sistema com base em permissões de usuário, o AppArmor restringe o que cada programa pode fazer — quais arquivos pode ler ou escrever, quais sockets pode abrir, quais capacidades do kernel pode usar — independentemente de quem o executou. Isso significa que, mesmo que um atacante explore uma vulnerabilidade no Nginx ou no MySQL e obtenha execução remota, o processo comprometido continua confinado pelo perfil AppArmor e não consegue ler /etc/shadow, escrever em /boot ou abrir conexões arbitrárias.
Desenvolvido originalmente pela Immunix e mantido atualmente pela Canonical, o AppArmor é o sistema de MAC padrão em distribuições como Ubuntu, Debian, openSUSE e SUSE Linux Enterprise. Sua principal diferença em relação a alternativas como SELinux é a abordagem baseada em caminhos de arquivos (pathname-based) em vez de rótulos (label-based), o que torna a curva de aprendizado significativamente mais suave para administradores de sistema.
Como funciona o AppArmor?
O AppArmor opera como um módulo carregado no kernel Linux que intercepta chamadas de sistema (syscalls) feitas por processos confinados e as compara com regras definidas em perfis textuais. Quando um programa tenta abrir um arquivo, executar um binário ou criar um socket, o AppArmor consulta o perfil ativo daquele processo e decide se permite ou nega a operação. Toda decisão é registrada via auditd ou no kernel log, permitindo análise forense posterior.
MAC vs DAC: a diferença fundamental
Sistemas Linux tradicionais usam DAC (Discretionary Access Control) — o modelo clássico de permissões rwx baseado em usuário, grupo e outros. Nesse modelo, o dono do arquivo decide quem pode acessá-lo. O problema é que, se um processo rodando como root for comprometido, ele herda todos os privilégios do root e pode fazer praticamente qualquer coisa no sistema.
O MAC (Mandatory Access Control) resolve isso impondo uma camada adicional de controle definida pelo administrador do sistema, não pelos donos individuais dos arquivos. Mesmo que um processo seja executado como root, o AppArmor pode restringir suas operações de acordo com o perfil. Essa é a base do princípio de menor privilégio aplicado a aplicações inteiras: um servidor web não precisa acessar /etc/sudoers, então não deve poder, mesmo rodando como root durante o bind na porta 80.
Perfis: a unidade de controle do AppArmor
Um perfil AppArmor é um arquivo de texto armazenado em /etc/apparmor.d/ que descreve exatamente o que um programa pode fazer. A sintaxe é declarativa e relativamente legível. Veja um exemplo simplificado de perfil para o Nginx:
#include <tunables/global>
/usr/sbin/nginx {
#include <abstractions/base>
#include <abstractions/nameservice>
capability net_bind_service,
capability setgid,
capability setuid,
/etc/nginx/** r,
/var/log/nginx/*.log w,
/var/www/** r,
/run/nginx.pid rw,
/usr/sbin/nginx mr,
deny /etc/shadow r,
deny /root/** rwx,
}O perfil acima permite ao Nginx fazer bind em portas privilegiadas, ler sua configuração, gravar logs e servir arquivos de /var/www, mas nega explicitamente leitura de /etc/shadow e qualquer acesso a /root. Mesmo um exploit que conseguisse RCE no Nginx esbarraria nessas restrições.
Modos enforce e complain
Cada perfil opera em um de dois modos. No modo enforce, o AppArmor bloqueia ativamente qualquer operação não permitida pelo perfil e registra a tentativa. É o modo de produção. No modo complain (também chamado de learning mode), o AppArmor não bloqueia nada — apenas registra todas as operações que teriam sido negadas. Esse modo é fundamental para desenvolver e ajustar perfis novos sem quebrar a aplicação.
A transição entre modos é feita com aa-enforce e aa-complain. Um terceiro estado, disabled, remove o perfil do kernel sem deletar o arquivo. Comandos básicos para gerenciar o estado dos perfis:
aa-status # lista perfis ativos
aa-enforce /etc/apparmor.d/usr.sbin.nginx
aa-complain /etc/apparmor.d/usr.sbin.mysqld
aa-disable /etc/apparmor.d/usr.sbin.cups
apparmor_parser -r /etc/apparmor.d/usr.sbin.nginxPara que serve o AppArmor?
O AppArmor cumpre três funções estratégicas em servidores Linux modernos: mitigação de vulnerabilidades, isolamento de aplicações e hardening sistêmico. Em ambientes de produção que servem milhares de requisições por segundo, ele atua como última linha de defesa quando outras camadas falham.
A mitigação de vulnerabilidades é o caso de uso mais imediato. Vulnerabilidades zero-day em aplicações populares são descobertas regularmente — basta lembrar de CVEs críticos em Apache, PHP, OpenSSL e bibliotecas SSL/TLS. Quando um perfil AppArmor está ativo, mesmo um exploit funcional fica limitado ao que o perfil permite. Um atacante que consiga RCE num WordPress mal configurado, por exemplo, não consegue escalar privilégios se o PHP-FPM estiver confinado.
O isolamento de aplicações faz com que serviços diferentes rodando no mesmo servidor não consigam interferir uns nos outros mesmo que comprometidos. Em um servidor com múltiplos sites WordPress, perfis bem desenhados impedem que um site invadido sirva como pivô para os demais. É similar ao isolamento oferecido por containers, mas funciona em processos diretamente no host.
O hardening sistêmico é o uso mais amplo: aplicar perfis a todos os serviços expostos à rede e a binários sensíveis (cups, snapd, evince, firefox em desktops) reduz drasticamente a superfície de ataque do sistema como um todo. Em servidores dedicados Ubuntu LTS modernos, o AppArmor já vem ativo por padrão com perfis para dezenas de serviços comuns.
Componentes do AppArmor
Entender os componentes individuais ajuda a diagnosticar problemas e a customizar o sistema para necessidades específicas. O AppArmor é composto por três grandes blocos: os perfis em si, o parser que os compila e as ferramentas de aprendizado.
Perfis (profiles)
Os perfis ficam em /etc/apparmor.d/ e seguem uma convenção de nomenclatura baseada no caminho do binário com pontos no lugar de barras. O perfil de /usr/sbin/nginx vira /etc/apparmor.d/usr.sbin.nginx. Perfis podem incluir abstractions (em /etc/apparmor.d/abstractions/) que agrupam regras comuns — abstractions/base inclui acesso a bibliotecas padrão, abstractions/nameservice permite resolução DNS, abstractions/nginx-common reúne regras típicas de servidores web.
Existe também o conceito de subperfis e perfis filhos (child profiles), que permitem que um processo execute outro com um perfil diferente do seu. Isso é essencial para casos como Nginx executando PHP-FPM via FastCGI, onde cada um precisa de um conjunto distinto de permissões.
Parser (apparmor_parser)
O apparmor_parser é o utilitário que compila perfis textuais em estruturas que o kernel consegue interpretar e carrega-as no Linux Kernel via interface securityfs. Sempre que um perfil é alterado, é necessário recarregá-lo com apparmor_parser -r ou systemctl reload apparmor. Erros de sintaxe no perfil resultam em falha do parser, e o perfil antigo continua ativo — comportamento seguro que evita derrubar a proteção por engano de digitação.
Ferramentas de aprendizado (aa-logprof, aa-genprof)
Escrever perfis do zero é trabalhoso. Por isso o AppArmor oferece ferramentas que automatizam parte do processo. O aa-genprof gera um perfil esqueleto para um binário e entra em modo interativo: ele coloca o programa em complain mode, pede para você exercitar a aplicação, e a cada operação registrada pergunta se deve permitir, negar ou criar uma abstração. O aa-logprof faz o trabalho complementar: analisa o log de complaints e sugere regras para incorporar ao perfil. Em servidores de produção, o fluxo típico é colocar uma aplicação em complain por algumas semanas, rodar aa-logprof, revisar as sugestões e ativar enforce.
AppArmor vs SELinux
A escolha entre AppArmor e SELinux divide administradores Linux há mais de uma década. Ambos implementam MAC, mas com filosofias diferentes que impactam diretamente operação, manutenção e expressividade das políticas.
O SELinux, desenvolvido pela NSA e mantido pela Red Hat, é baseado em rótulos (labels). Cada arquivo, processo, socket e recurso do sistema recebe um contexto de segurança no formato user:role:type:level. As políticas operam sobre esses rótulos, não sobre caminhos. Isso significa que renomear ou mover um arquivo não muda suas permissões SELinux (o rótulo viaja com o arquivo via xattrs), o que é uma vantagem em termos de robustez — mas exige uma camada inteira de gerenciamento de contextos (restorecon, semanage, chcon) que não existe no AppArmor.
O AppArmor é baseado em caminhos (pathname-based). As regras operam diretamente sobre caminhos do filesystem com suporte a globbing. É conceitualmente mais simples e a curva de aprendizado é muito mais curta. A contrapartida é que renomear arquivos pode escapar das regras — embora, na prática, os caminhos cobertos por perfis são os de configuração e binários instalados via package manager, que raramente mudam de lugar.
| Aspecto | AppArmor | SELinux |
|---|---|---|
| Modelo | Path-based | Label-based |
| Curva de aprendizado | Suave | Íngreme |
| Distribuições padrão | Ubuntu, Debian, openSUSE | RHEL, CentOS Stream, Fedora, Rocky |
| Sintaxe | Declarativa, legível | Complexa, requer compilação |
| Granularidade | Média-alta | Muito alta |
| Uso típico | Hardening pragmático | Ambientes regulados, defesa |
Em servidores dedicados rodando Ubuntu ou Debian, AppArmor é a escolha natural e suficiente para a grande maioria dos casos de uso. SELinux faz mais sentido em ambientes Red Hat ou onde regulações específicas (FedRAMP, certificações governamentais) exigem o modelo mais rigoroso de rótulos.
Vantagens e desvantagens do AppArmor
Como toda solução de segurança, AppArmor traz benefícios e custos operacionais que devem ser pesados antes da adoção em escala.
Vantagens:
- Sintaxe legível: perfis são arquivos de texto que qualquer administrador consegue ler e auditar sem ferramentas especiais.
- Ativação granular: é possível confinar apenas alguns serviços críticos sem afetar o resto do sistema.
- Modo complain: permite implantar perfis em produção sem risco de quebrar aplicações, gerando logs para ajuste posterior.
- Integração com o kernel: sendo um LSM oficial, o desempenho é excelente — overhead típico abaixo de 5% mesmo em workloads intensivos.
- Pacotes pré-empacotados: dezenas de perfis vêm prontos em pacotes como apparmor-profiles e apparmor-profiles-extra no Ubuntu/Debian.
Desvantagens:
- Path-based limita robustez: renomear binários ou alterar caminhos pode contornar regras (mitigável com perfis bem desenhados).
- Falta de granularidade em alguns cenários: SELinux oferece controle mais fino sobre operações específicas como ioctl e capabilities.
- Curva de manutenção: ao atualizar aplicações, novos comportamentos podem quebrar perfis existentes, exigindo manutenção contínua.
- Documentação irregular: alguns recursos avançados (subperfis, hat profiles) têm documentação esparsa e exigem leitura do código.
- Suporte limitado em distribuições não-Debianas: em RHEL e derivados, a integração padrão é com SELinux, e usar AppArmor exige trabalho adicional.
Erros comuns ao usar AppArmor
Administradores que adotam AppArmor frequentemente cometem erros previsíveis que minam a eficácia da proteção ou geram problemas operacionais. Reconhecer essas armadilhas antecipadamente economiza horas de troubleshooting.
1. Ativar enforce sem passar por complain. Aplicar um perfil novo diretamente em modo enforce em produção quase sempre causa erros silenciosos: arquivos que não são lidos, sockets que falham em abrir, logs que somem. Sempre comece em complain por dias ou semanas, analise o log e só então mude para enforce.
2. Ignorar logs de auditd. AppArmor registra cada DENIED em /var/log/audit/audit.log (com auditd) ou em /var/log/kern.log. Administradores que não monitoram esses logs perdem sinais de tentativas de exploração reais e também perdem indicações de que o perfil está mal configurado. Ferramentas como aa-notify ajudam a centralizar.
3. Perfis muito restritivos sem testes. O excesso de zelo em negar tudo que parece desnecessário leva a perfis que quebram funcionalidades legítimas. O caso clássico é o MySQL que perde a capacidade de criar arquivos temporários, ou o Nginx que não consegue reabrir logs após logrotate.
4. Esquecer de recarregar após editar. Alterar um perfil em /etc/apparmor.d/ sem rodar apparmor_parser -r ou systemctl reload apparmor faz com que a mudança seja ignorada até o próximo boot. O perfil ativo no kernel não muda automaticamente quando o arquivo muda.
5. Debug sem aa-logprof. Tentar adivinhar quais regras adicionar lendo logs brutos é exaustivo. O aa-logprof processa os logs e sugere regras formatadas que você só precisa revisar e aceitar ou rejeitar. Use-o.
6. Confundir AppArmor com firewall. AppArmor não substitui iptables, nftables ou UFW. Ele controla o que processos fazem, não o tráfego que entra ou sai do servidor. As duas camadas são complementares.
7. Não versionar perfis customizados. Perfis editados manualmente são reescritos por atualizações de pacote se você não os versionar em ferramentas como Ansible ou git. Sempre coloque /etc/apparmor.d/ sob controle de versão e use overrides locais quando possível.
AppArmor e a Shiftmind
O hardening com AppArmor é parte do trabalho técnico que faz diferença real em infraestrutura crítica. Configurar perfis bem desenhados para Nginx, MySQL, PHP-FPM e demais serviços não é tarefa trivial — exige conhecimento profundo do comportamento das aplicações e disciplina operacional para manter os perfis atualizados conforme novas versões são lançadas.
Na Shiftmind, esse trabalho é integrado aos serviços de servidor dedicado e hospedagem WordPress. Cada servidor que provisionamos recebe um conjunto de perfis AppArmor revisado para o stack que vai rodar, com regras específicas para o WordPress, sua versão do PHP e o servidor web escolhido. Isso significa que mesmo um plugin vulnerável encontra barreiras que limitam o estrago possível.
O serviço de hospedagem gerenciada inclui revisão periódica desses perfis e ajustes conforme novos plugins ou comportamentos são introduzidos no ambiente. Para clientes que já possuem servidores em outras hospedagens, oferecemos suporte e manutenção com auditoria do estado atual do AppArmor e implementação de perfis customizados. E como hardening de processos é apenas uma camada de uma estratégia de defesa em profundidade, complementamos com segurança de websites envolvendo WAF, scanners de malware e monitoramento contínuo.
Termos relacionados
- ACL (Access Control List) — controle de acesso granular como camada complementar.
- Active Directory — gestão centralizada de identidades em ambientes corporativos.
- Alta Disponibilidade (High Availability) — combinada com hardening forma a base de infraestrutura resiliente.
- Afinidade de Sessão (Session Affinity) — relevante em load balancers de aplicações confinadas.
- AMD EPYC — processadores comuns em servidores dedicados modernos.
- Ansible — ferramenta ideal para versionar e aplicar perfis AppArmor em escala.
- Apache — servidor web com perfis AppArmor disponíveis em apparmor-profiles.
- Apache Kafka — workload distribuído que se beneficia de confinamento por processo.
- API Gateway — ponto de entrada crítico que deve ser hardened com MAC.
Outros termos relacionados sem link próprio no glossário ainda: SELinux, Linux Kernel, MAC, DAC, Ubuntu, Debian, Container, Docker, AppArmor profiles.
Conclusão
AppArmor representa o equilíbrio pragmático entre rigor de segurança e usabilidade operacional no ecossistema Linux. Sua abordagem path-based e sintaxe legível tornam viável adotar MAC em produção sem o custo de aprendizado vertical do SELinux, e a integração nativa com Ubuntu e Debian garante que a maioria dos servidores web e bancos de dados possa começar a usá-lo imediatamente.
O ponto-chave é tratar AppArmor como camada complementar, não como solução isolada. Combinado com firewall bem configurado, atualizações regulares, monitoramento de logs e princípio de menor privilégio aplicado a usuários e serviços, ele eleva significativamente o custo de exploração de vulnerabilidades. Em servidores dedicados que hospedam aplicações críticas, a ausência de perfis AppArmor (ou SELinux) é hoje considerada lacuna de hardening básico.
Precisa de servidores Linux configurados com hardening AppArmor desde o provisionamento? A Shiftmind cuida da infraestrutura para que você foque no negócio. Entre em contato e converse com nosso time técnico.
