SELinux e AppArmor: Reforçando a Segurança do Linux de Forma Eficaz

Introdução aos Mecanismos de Controle de Acesso no Linux

No universo linux, a segurança é construída em camadas. A base mais conhecida é o Controle de acesso Discricionário (DAC), o sistema de permissões de usuário, grupo e outros (rwx) que administramos com comandos como chmod e chown. Embora eficaz para o isolamento de dados de usuários, o DAC possui uma limitação fundamental: se um processo for comprometido, ele herda todas as permissões do usuário que o executou. Um servidor web rodando como o usuário www-data, se explorado, pode potencialmente acessar qualquer arquivo que o usuário www-data possa ler.

Para mitigar esse risco, foram desenvolvidos os sistemas de Controle de Acesso Mandatório (MAC). Um sistema MAC adiciona uma camada de segurança adicional, aplicando uma política de segurança centralizada em todo o sistema, que é imposta pelo kernel. As decisões de acesso não se baseiam apenas na identidade do usuário, mas em um conjunto complexo de regras e rótulos de segurança. Os dois principais sistemas MAC no Linux são o SELinux (Security-Enhanced Linux) e o AppArmor (Application Armor). Este artigo explora em profundidade ambos os sistemas, suas filosofias de funcionamento, comandos essenciais e estratégias para gerenciá-los sem causar instabilidade no ambiente.

Compreendendo o SELinux (Security-Enhanced Linux)

Originalmente desenvolvido pela Agência de Segurança Nacional dos EUA (NSA), o SELinux foi integrado ao kernel Linux e tornou-se o padrão em distribuições da família Red Hat, como RHEL, CentOS, Rocky Linux e Fedora. Sua abordagem é baseada em rotulagem, onde cada objeto do sistema — processos, arquivos, diretórios, soquetes de rede, portas — recebe um rótulo de segurança, chamado de contexto.

O Conceito de Contextos de Segurança

Um contexto SELinux é composto por quatro partes: user:role:type:level. Para a maioria das tarefas de administração, o componente mais importante é o tipo (type). A política do SELinux consiste em um vasto conjunto de regras que definem como os tipos podem interagir. Por exemplo, uma regra pode permitir que um processo com o tipo httpd_t (um processo do servidor Apache) leia arquivos com o tipo httpd_sys_content_t.

Qualquer tentativa de ação que não esteja explicitamente permitida na política é bloqueada pelo kernel. Isso significa que, mesmo que um invasor comprometa o processo do Apache, ele só poderá realizar as ações permitidas para o tipo httpd_t, limitando drasticamente o dano potencial.

Modos de Operação do SELinux

O SELinux pode operar em três modos distintos:

  • Enforcing: O modo padrão e totalmente ativo. A política de segurança é aplicada e todas as violações são bloqueadas e registradas (logadas).
  • Permissive: Neste modo, o SELinux não bloqueia nenhuma ação. No entanto, ele registra todas as violações de política que teriam sido bloqueadas no modo Enforcing. É extremamente útil para depuração e desenvolvimento de novas políticas.
  • Disabled: O módulo SELinux é completamente desativado no kernel. Requer uma reinicialização do sistema para ser ativado novamente.

Comandos Essenciais para Gerenciamento

A interação com o SELinux é feita através de um conjunto de ferramentas de linha de comando:

  • sestatus: Exibe o estado atual do SELinux, incluindo o modo, a política carregada e os contextos de arquivos.
  • getenforce / setenforce [0|1]: Permitem visualizar e alterar o modo de operação entre Permissive (0) e Enforcing (1) em tempo real, sem necessidade de reboot.
  • ls -Z e ps auxZ: Exibem os contextos de segurança de arquivos e processos, respectivamente.
  • chcon: Altera o contexto de um arquivo temporariamente. Essa alteração não sobrevive a uma re-rotulagem do sistema. Ex: chcon -t httpd_sys_content_t /srv/novosite.
  • restorecon: Restaura o contexto padrão de um arquivo ou diretório, lendo as regras da política de sistema. É a forma correta de corrigir contextos incorretos. Ex: restorecon -Rv /var/www/.
  • semanage: Ferramenta poderosa para realizar alterações permanentes na política do SELinux. Por exemplo, para definir um contexto padrão para um novo diretório: semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?", seguido por um restorecon.

Troubleshooting de Negações (AVC Denials)

O desafio mais comum é quando o SELinux bloqueia uma operação legítima. Essas negações são registradas como mensagens “AVC denied” no log de auditoria, geralmente em /var/log/audit/audit.log. As ferramentas audit2why e audit2allow são essenciais para interpretar esses logs e sugerir soluções.

Um cenário clássico: você altera a porta padrão do SSH para 2222. O serviço não inicia. Ao verificar os logs, você encontra uma negação do SELinux. A solução é usar o semanage para informar à política que o processo SSHD agora tem permissão para operar na porta 2222: semanage port -a -t ssh_port_t -p tcp 2222.

Explorando o AppArmor (Application Armor)

O AppArmor adota uma filosofia diferente. Padrão em distribuições como Ubuntu, Debian e SUSE, ele foca em confinar programas individuais em vez de rotular todo o sistema. Sua abordagem é baseada em caminhos de arquivos (path-based).

O Sistema de Perfis (Profiles)

No AppArmor, a política de segurança é definida através de “perfis” (profiles), que são arquivos de texto simples localizados em /etc/apparmor.d/. Cada perfil está associado a um executável específico, como /usr/sbin/nginx. Dentro do perfil, são definidas regras que especificam quais arquivos o programa pode ler, escrever ou executar, quais capacidades de rede ele pode usar, e outras restrições.

Exemplo de uma regra simples em um perfil AppArmor:

/var/www/html/index.html r,

Esta linha permite que o programa associado ao perfil leia (r) o arquivo index.html. A sintaxe é considerada mais intuitiva e legível em comparação com a complexidade das políticas do SELinux.

Modos de Operação do AppArmor

Similarmente ao SELinux, o AppArmor possui modos de operação, mas aplicados por perfil:

  • enforce: O perfil está ativo, e todas as violações são bloqueadas e registradas.
  • complain: O perfil não bloqueia nenhuma ação, mas registra todas as violações. Ideal para desenvolver ou ajustar um perfil sem quebrar a aplicação.
  • disabled: O perfil não é carregado na memória pelo kernel.

Ferramentas de Gerenciamento do AppArmor

O ecossistema do AppArmor fornece um conjunto de utilitários para facilitar a administração:

  • aa-status: O comando principal para verificar o status do AppArmor. Ele lista todos os perfis carregados e seus respectivos modos (enforce, complain ou unloaded).
  • aa-enforce <profile>: Coloca um perfil específico em modo enforce.
  • aa-complain <profile>: Coloca um perfil específico em modo complain.
  • aa-genprof <executável>: Uma ferramenta interativa para gerar um novo perfil. Você executa o programa em um terminal enquanto o aa-genprof monitora suas atividades no sistema, perguntando ao administrador quais ações devem ser permitidas.
  • aa-logprof: Examina os logs do sistema em busca de negações do AppArmor e oferece uma interface interativa para atualizar perfis existentes, permitindo ou negando as ações registradas.

Resolvendo Problemas com AppArmor

As negações do AppArmor são tipicamente registradas no log geral do kernel (acessível via dmesg) ou no log de auditoria. A ferramenta aa-logprof é o método recomendado para resolver esses problemas. Ao executá-la, ela analisará os logs e apresentará cada violação, permitindo que você adicione uma nova regra ao perfil correspondente com facilidade.

SELinux vs. AppArmor: Uma Análise Comparativa

Embora ambos busquem o mesmo objetivo — impor o Controle de Acesso Mandatório — suas abordagens e complexidades são distintas.

Abordagem e Granularidade

O SELinux, com seu sistema de rotulagem, é mais abrangente e granular. Ele controla interações entre todos os tipos de objetos, não apenas processos e arquivos. Isso permite, por exemplo, políticas de segurança multinível (MLS), mas introduz uma complexidade de gerenciamento muito maior. O AppArmor, sendo baseado em caminhos, é mais simples de entender e configurar, focando na contenção de aplicações específicas.

Complexidade e Curva de Aprendizagem

O AppArmor é amplamente considerado mais fácil de aprender e usar. A criação e edição de perfis em texto plano são tarefas mais diretas. O SELinux exige um entendimento mais profundo de sua arquitetura de tipos, papéis e contextos. Resolver problemas no SELinux pode ser mais desafiador para administradores iniciantes.

Ecossistema e Distribuições

A escolha entre os dois é frequentemente ditada pela distribuição Linux utilizada. Ambientes corporativos baseados em RHEL e seus derivados se beneficiarão da robustez e do forte suporte ao SELinux. Desenvolvedores e administradores em plataformas baseadas em Debian/Ubuntu encontrarão no AppArmor uma solução bem integrada e mais acessível.

Gerenciamento Prático: Dicas para Não Quebrar o Sistema

O medo de quebrar aplicações leva muitos administradores a desativar o SELinux ou o AppArmor. Esta é uma prática perigosa. Com a abordagem correta, é possível manter a segurança reforçada sem interrupções.

1. Nunca Desative, Use o Modo Permissivo/Complain

Ao instalar um novo software ou realizar uma grande alteração de configuração, mude temporariamente para o modo Permissive (SELinux) ou Complain (AppArmor). Deixe a aplicação rodar, execute todos os seus casos de uso e colete os logs de violações. Use as ferramentas de auditoria para criar as regras necessárias. Após os testes, retorne ao modo Enforcing.

2. Domine as Ferramentas de Log e Auditoria

Aprenda a ler /var/log/audit/audit.log e a usar audit2why no SELinux. Familiarize-se com a saída de dmesg | grep 'apparmor="DENIED"' e o fluxo de trabalho de aa-logprof no AppArmor. Os logs são seus melhores amigos; eles informam exatamente o que foi bloqueado, por quê e qual processo/arquivo estava envolvido.

3. Entenda os Booleans do SELinux

Muitas políticas comuns no SELinux podem ser ativadas ou desativadas através de “booleans”, que são interruptores on/off. Antes de escrever uma regra complexa, verifique se já não existe um boolean para o que você precisa. Use getsebool -a para listar todos e setsebool -P [nome_do_boolean] on para ativar um permanentemente. Um exemplo comum é setsebool -P httpd_can_network_connect on para permitir que o Apache faça conexões de rede.

4. Cuidado com o Contexto de Arquivos (SELinux)

Um erro frequente é mover (mv) arquivos em vez de copiá-los (cp). O comando mv preserva o contexto de segurança original do arquivo, o que pode torná-lo inacessível em seu novo local. Sempre que mover arquivos para um diretório gerenciado pelo SELinux (como /var/www/html), execute um restorecon -Rv no diretório de destino para corrigir os contextos.

Aplicações em Ambientes Modernos e Próximos Passos

Em infraestruturas modernas baseadas em contêineres, tanto o SELinux quanto o AppArmor desempenham um papel vital. Motores de contêiner como Docker e Podman utilizam esses mecanismos para fortalecer o isolamento entre contêineres e o host. Eles geram automaticamente perfis AppArmor ou contextos SELinux para cada contêiner, limitando drasticamente o que um contêiner comprometido pode fazer no sistema hospedeiro. Compreender os fundamentos do MAC é, portanto, crucial para a segurança de contêineres.

Para aprofundar seus conhecimentos, a documentação oficial é o melhor recurso. A Red Hat possui um guia extensivo sobre SELinux, enquanto o Wiki do AppArmor no site do Ubuntu oferece informações detalhadas sobre a criação e gerenciamento de perfis. Dominar essas ferramentas não é apenas sobre corrigir erros, mas sobre projetar e implementar proativamente uma infraestrutura Linux mais segura e resiliente.