Aula 22: SELinux e AppArmor — controle de acesso obrigatório (MAC)

No ecossistema de segurança Linux, as permissões tradicionais de arquivos e o modelo de usuário/grupo constituem apenas a primeira camada de defesa. Quando falamos de ambientes corporativos, servidores expostos à internet, infraestrutura crítica e conformidade com normas como PCI‑DSS ou ISO 27001, o Controle de Acesso Obrigatório (Mandatory Access Control — MAC) deixa de ser um diferencial e se torna uma exigência. É aqui que entram SELinux e AppArmor, os dois principais sistemas MAC para Linux, capazes de restringir processos mesmo quando executados por usuários privilegiados. Nesta aula, vamos dominar ambos: da teoria que fundamenta o MAC à criação de políticas personalizadas, passando por diagnóstico de violações, ajuste fino e integração com serviços reais como Apache e MySQL. Em nossos projetos na JRT Technology Solutions, SELinux e AppArmor são os pilares que impedem que uma aplicação comprometida escale privilégios — e você aprenderá por que configurá‑los corretamente é a diferença entre um incidente contido e uma violação catastrófica.

O Controle de Acesso Discricionário (DAC) — as permissões rwx e os ACLs que estudamos nas aulas anteriores — depende da vontade do proprietário do recurso: se um arquivo pertence a root e tem permissão 0777, qualquer processo pode lê‑lo ou alterá‑lo. Já o MAC impõe uma política centralizada, inegociável, definida pelo administrador do sistema, que se sobrepõe ao DAC. Mesmo que um invasor consiga executar código como root ou apache, as regras do MAC podem bloquear o acesso a diretórios sensíveis, limitar o tráfego de rede do processo ou impedir a transição de domínio de segurança. Essa camada extra é exatamente o que buscamos ao implementar uma estratégia de defesa em profundidade — conceito que nossos especialistas utilizam diariamente em implantações de servidores Linux blindados.

Nesta aula avançada, o leitor que já domina permissões, firewalls e hardening básico dará um salto de maturidade. Vamos partir dos fundamentos: por que o kernel suporta dois subsistemas MAC distintos e em quais distribuições cada um é padrão. Em seguida, mergulharemos nos modos operacionais (enforcing, permissive, disabled para SELinux; enforce e complain para AppArmor), nas ferramentas de linha de comando que os tornam práticos, e na anatomia de um contexto de segurança e de um perfil de aplicação. Tudo isso com exemplos reais, executados passo a passo, que você pode replicar em sua máquina virtual agora mesmo.

Ao final desta aula, você não apenas entenderá as diferenças arquiteturais entre SELinux e AppArmor, como será capaz de: identificar e interpretar alertas de violação, criar políticas customizadas para binários ou contêineres, ajustar booleanos sem desabilitar a proteção, e restaurar contextos em sistemas de arquivos corrompidos por operações inadequadas. Essas habilidades são frequentemente testadas em certificações como RHCE, CompTIA Linux+ e em entrevistas técnicas para posições de segurança ofensiva e defensiva.

O que você vai aprender nesta aula

• Diferenciar DAC de MAC e compreender onde cada um se encaixa na arquitetura de segurança do Linux
• Identificar a distribuição padrão de SELinux e AppArmor nas principais famílias de Linux (RHEL/CentOS/Rocky vs Ubuntu/Debian/SUSE)
• Configurar e alternar entre os modos operacionais de ambos os sistemas sem comprometer a estabilidade
• Interpretar e manipular contextos de segurança SELinux (user:role:type:level) e rótulos AppArmor
• Criar, aplicar e gerenciar políticas de perfil para serviços web, bancos de dados e aplicações personalizadas
• Utilizar as ferramentas de diagnóstico (audit2allow, audit2why, aa-logprof, aa-genprof) para resolver violações sem desabilitar a proteção
• Implementar hardening de containers Docker/Podman com perfis AppArmor e políticas SELinux adaptadas

Pré-requisitos e Ambiente

Para executar todos os laboratórios desta aula, você precisará de pelo menos duas máquinas virtuais x86_64: uma baseada em RHEL 9 (Rocky Linux 9, AlmaLinux 9 ou CentOS Stream 9) e outra baseada em Ubuntu Server 24.04 LTS. Recomenda‑se 2 GB de RAM e 20 GB de disco para cada VM. O conhecimento de comandos de gerência de pacotes (dnf / apt), edição de arquivos via vim ou nano, e familiaridade com serviço systemd são essenciais. Garanta que o sistema esteja atualizado (dnf update -y ou apt update && apt upgrade -y) e que o serviço de auditoria (auditd) esteja ativo, pois é a base de logs do SELinux. Se você não possui o pacote policycoreutils-python-utils (RHEL) ou apparmor-utils (Ubuntu), nós os instalaremos durante os procedimentos. Esta aula assume que o DAC básico já está configurado, pois focaremos exclusivamente na camada MAC.

1. Fundamentos do Controle de Acesso Obrigatório e Arquiteturas

O MAC opera em nível de kernel, integrando‑se ao subsistema de segurança Linux Security Modules (LSM). Quando uma chamada de sistema é feita — por exemplo, open(), execve() ou connect() — o kernel primeiro verifica as permissões DAC tradicionais. Se o DAC permitir, a chamada é repassada ao gancho LSM ativo, onde a política MAC decide se a operação será autorizada ou negada. Essa arquitetura garante que mesmo um processo rodando com uid 0 possa ser confinado a um subconjunto mínimo de recursos, seguindo o princípio do menor privilégio. Existem vários LSM disponíveis, mas SELinux e AppArmor dominam o espaço Linux; outros, como Smack e TOMOYO, têm adoção mais restrita. Cada um implementa o MAC de maneira distinta: SELinux usa um modelo baseado em labeling (rótulos em cada objeto e sujeito) com políticas complexas e regras explícitas, enquanto o AppArmor é path‑based (baseado em caminhos de arquivo), tornando‑o mais simples de perfilar mas menos granular em certos cenários.

O SELinux foi desenvolvido originalmente pela NSA e adotado pelo Red Hat como padrão desde o RHEL 4. Ele opera com políticas do tipo targeted (a padrão), que confina apenas processos críticos, ou strict, que confina todos os processos. Cada arquivo, processo, porta de rede e socket recebe um contexto de segurança composto por quatro campos: usuário, papel, tipo (ou domínio, para processos) e nível (usado em MLS/MCS). É o campo type que governa a maioria das regras; por exemplo, um processo com tipo httpd_t só pode ler arquivos com tipo httpd_sys_content_t, independentemente das permissões DAC. Já o AppArmor, desenvolvido pela Immunix e hoje mantido pela Canonical (padrão no Ubuntu desde 7.04), utiliza perfis textuais que declaram, com base em caminhos, quais arquivos um programa pode ler, escrever, executar, mapear em memória ou acessar via rede. Um perfil AppArmor pode estar em modo enforce (bloqueia e registra) ou complain (apenas registra), facilitando o ajuste gradual.

A decisão de qual sistema MAC adotar normalmente já vem tomada pela distribuição, mas em ambientes heterogêneos ou em migrações, conhecer ambos é crucial. Em nossos projetos na JRT Technology Solutions, frequentemente integramos servidores RHEL com appliances Debian e, em todos, configuramos o MAC nativo — SELinux nos servidores de banco de dados Oracle e AppArmor nos balanceadores NGINX — garantindo que a política de segurança seja uniforme mesmo que a ferramenta mude. Vale destacar que é possível compilar o kernel com suporte a múltiplos LSMs, mas apenas um pode estar ativo por vez para MAC; o Ubuntu, por exemplo, carrega AppArmor como padrão, mas permite instalar e ativar SELinux caso se remova o AppArmor.

2. SELinux: Modos de Operação, Contextos e Comandos Essenciais

No ecossistema RHEL/Rocky/CentOS, o SELinux é ativado por padrão no modo enforcing assim que o sistema é instalado. O comando getenforce retorna o estado atual; sestatus oferece detalhes como a política carregada, o modo corrente e o modo configurado no arquivo /etc/selinux/config. Os três modos possíveis são: enforcing (política ativa, violações bloqueadas e logadas), permissive (política ativa, violações apenas logadas — útil para depuração) e disabled (totalmente desligado, requer reinicialização para reativar). Nunca desabilite permanentemente o SELinux em produção; se um aplicação apresentar problemas, coloque-a em permissivo, colete os logs e crie uma política sob medida. Para alterar o modo em tempo de execução, usa‑se setenforce: setenforce 0 para permissivo, setenforce 1 para enforcing. A mudança não sobrevive ao reboot; para torná‑la persistente, edite o parâmetro SELINUX=enforcing no arquivo de configuração.

O coração do SELinux são os contextos de segurança. Todo arquivo, diretório, processo, porta TCP/UDP e objeto IPC carrega um contexto estendido visível com a flag -Z na maioria dos comandos (ls -Z, ps -eZ, netstat -Z). O formato system_u:object_r:httpd_sys_content_t:s0 se decodifica da seguinte forma: system_u (usuário SELinux, não confundir com o usuário Linux), object_r (papel, tipicamente object_r para arquivos), httpd_sys_content_t (tipo, a parte mais relevante) e s0 (nível de sensibilidade). Processos em execução exibem o tipo como domínio — por exemplo, unconfined_service_t ou httpd_t. As transições de domínio são controladas pela política e só ocorrem se houver uma regra explícita type_transition.

Ferramentas essenciais do pacote policycoreutils-python-utils (RHEL) permitem manipular contextos e booleanos. semanage é o canivete suíço: gerencia portas, contextos de arquivo, booleanos e usuários SELinux. restorecon restaura o contexto padrão de arquivos com base nas especificações do /etc/selinux/targeted/contexts/files/file_contexts. chcon altera temporariamente o contexto de um arquivo, mas a mudança se perde ao restaurar com restorecon. sealert e audit2allow analisam os logs de auditoria (/var/log/audit/audit.log) e sugerem alterações de política. Por fim, setsebool e getsebool controlam os booleanos — chaves que habilitam ou desabilitam comportamentos específicos da política sem recompilá‑la, extremamente úteis para ajustes finos como permitir que o Apache faça conexões de rede (httpd_can_network_connect).

3. Passo a Passo — Instalando, Verificando e Configurando SELinux no Rocky Linux 9

Para este laboratório, assumimos um sistema Rocky Linux 9 recém-instalado com o perfil “Server with GUI” ou “Minimal Install”. O SELinux já estará presente e ativo, mas vamos verificar e simular um cenário completo: ajustar o modo, criar um diretório web personalizado fora do /var/www, ajustar contextos e resolver violações sem desativar a proteção. Este é exatamente o tipo de tarefa que executo em treinamentos corporativos da JRT Technology Solutions, por isso preste atenção em cada comando e saída.

1. Atualize o sistema e confirme a instalação dos pacotes de auditoria e ferramentas SELinux.

   # Atualização completa do sistema
   dnf update -y
   
   # Instalação dos pacotes essenciais para gerenciamento e diagnóstico
   dnf install -y policycoreutils-python-utils setroubleshoot setools-console audit
   
   # Habilita e inicia o serviço de auditoria (já deve estar ativo por padrão)
   systemctl enable --now auditd
   
   # Verifica o status detalhado do SELinux
   sestatus

   SELinux status:                 enabled
   SELinuxfs mount:                /sys/fs/selinux
   SELinux root directory:         /etc/selinux
   Loaded policy name:             targeted
   Current mode:                   enforcing
   Mode from config file:          enforcing
   Policy MLS status:              enabled
   Policy deny_unknown status:     allowed
   Memory protection checking:     actual (secure)
   Max kernel policy version:      33

   Essa saída confirma que o SELinux está ativo, carregando a política targeted no modo enforcing. O MLS status como enabled indica que o suporte a múltiplos níveis está compilado, embora não usemos a política MLS agora.

2. Instale o servidor web Apache e crie um diretório de conteúdo fora do padrão. A intenção é provocar um bloqueio proposital do SELinux para aprendermos a diagnosticá‑lo.

   dnf install -y httpd
   systemctl enable --now httpd
   
   # Cria o diretório /web (incomum) e um arquivo index.html
   mkdir -p /web
   echo "<h1>SELinux Lab - JRT Technology Solutions</h1>" > /web/index.html
   
   # Ajusta o DocumentRoot do Apache
   sed -i 's|/var/www/html|/web|g' /etc/httpd/conf/httpd.conf
   
   # Reinicia o serviço
   systemctl restart httpd

   Neste ponto, se tentarmos acessar http://localhost com curl http://localhost, receberemos um erro 403 Forbidden ou uma página vazia, dependendo das configurações. O SELinux bloqueou o acesso porque o diretório /web não possui o contexto adequado.

3. Diagnostique a violação SELinux usando os logs de auditoria.

   # Verifica os alertas mais recentes com sealert
   sealert -a /var/log/audit/audit.log | tail -30
   
   # Alternativa rápida: buscar por AVC (Access Vector Cache) denials
   ausearch -m avc -ts recent

   ----
   time->Sat Jul 25 14:22:10 2026
   type=AVC msg=audit(1720...): avc:  denied  { getattr } for  pid=4523 comm="httpd" path="/web/index.html" dev="dm-0" ino=56789 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0
   ----

   O kernel está nos informando que o sujeito (scontext) com tipo httpd_t tentou a operação getattr no objeto (tcontext) com tipo default_t e foi negado. O tipo default_t indica que o diretório e arquivo herdaram o contexto do ponto de montagem ou do diretório pai sem regra específica. A solução não é desabilitar o SELinux, e sim atribuir o contexto correto.

4. Corrija os contextos usando semanage e restorecon.

   # Define o contexto padrão para o diretório /web e seus filhos (recursivo)
   semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"
   
   # Aplica os contextos corretos recursivamente
   restorecon -Rv /web
   
   # Verifica se o contexto foi alterado
   ls -Z /web/

   unconfined_u:object_r:httpd_sys_content_t:s0 index.html

   O semanage fcontext grava uma regra persistente em /etc/selinux/targeted/contexts/files/file_contexts.local. O restorecon lê essa base e ajusta os atributos estendidos no sistema de arquivos. Agora, ao repetir curl http://localhost, a página será exibida corretamente.

5. Teste o acesso e confirme que não há novas violações.

   curl http://localhost
   ausearch -m avc -ts recent | grep httpd

   A ausência de novas entradas AVC confirma que a política está sendo cumprida.

4. Booleanos SELinux — Ajuste Fino sem Reescrever a Política

Um dos recursos mais poderosos do SELinux, e infelizmente subutilizado, são os booleanos. Trata‑se de opções binárias que a política targeted expõe para que o administrador habilite ou desabilite comportamentos específicos sem precisar criar um módulo customizado. Existem dezenas de booleanos para serviços como Apache, MySQL, FTP, NFS, entre outros. Para listar todos com uma breve descrição, use semanage boolean -l. Para filtrar os relacionados ao Apache: semanage boolean -l | grep httpd. Cada booleano pode ser lido com getsebool e alterado com setsebool. O parâmetro -P torna a mudança persistente após reboot.

Vamos a um cenário prático: imagine que seu Apache precise conectar‑se a um backend de banco de dados ou a um serviço REST externo. Por padrão, a política SELinux bloqueia conexões de rede originadas por processos no domínio httpd_t, uma medida clássica de defesa em profundidade — mesmo que um atacante consiga executar código dentro do Apache, ele não conseguirá estabelecer conexões reversas ou vazar dados pela rede. Para habilitar essa funcionalidade de forma consciente, usamos o booleano httpd_can_network_connect.

# Verifica o estado atual (deve retornar off)
getsebool httpd_can_network_connect

# Habilita e persiste
setsebool -P httpd_can_network_connect on

# Confirma a alteração
getsebool httpd_can_network_connect

httpd_can_network_connect --> on

Outro exemplo comum: servidores web que precisam enviar e‑mails via sendmail (comum em formulários PHP legados). O booleano httpd_can_sendmail controla esse privilégio. Em nossos projetos na JRT Technology Solutions, criamos um checklist de booleanos necessários para cada aplicação que implantamos, documentando‑os no playbook Ansible correspondente, de modo que a segurança não seja comprometida por conveniência. A tabela a seguir compila os booleanos mais frequentemente ajustados em ambientes de produção.

É fundamental lembrar que booleanos devem ser habilitados apenas após análise de risco. Cada “on” aumenta a superfície de ataque potencial do serviço. Felizmente, o SELinux registra toda concessão nos logs, permitindo auditoria posterior.

5. Criando um Módulo de Política SELinux Personalizado com audit2allow

Em situações onde a política padrão não cobre uma aplicação legítima — seja um binário desenvolvido internamente, seja um serviço instalado em diretório não padrão — precisamos criar um módulo SELinux customizado. O fluxo de trabalho maduro consiste em: (1) colocar o sistema em modo permissive apenas para o domínio problemático, (2) exercitar todas as funcionalidades da aplicação, (3) coletar os logs AVC, (4) gerar um módulo de política com audit2allow, (5) revisar e compilar o módulo, e (6) restaurar o modo enforcing e carregar a nova política. Esse método garante que nenhuma permissão excessiva seja concedida.

Vamos simular uma aplicação fictícia /opt/myapp/bin/server que precisa gravar logs em /var/log/myapp/. Assumimos que o binário foi copiado manualmente e, ao ser iniciado, gera violações AVC repetidas. Para isolar a depuração, primeiro colocamos apenas o domínio relevante em permissivo (se soubermos qual é) ou o sistema todo temporariamente. Em cenários reais, é mais seguro usar semanage permissive para liberar apenas o domínio. Suponha que o processo execute como unconfined_t inicialmente (caso contrário, já teria transição controlada). Vamos ao passo a passo completo:

# 1. Cria o diretório da aplicação e o binário de exemplo
mkdir -p /opt/myapp/bin /var/log/myapp
cat > /opt/myapp/bin/server << 'EOF'
#!/bin/bash
echo "Server started at $(date)" >> /var/log/myapp/server.log
while true; do sleep 60; done
EOF
chmod +x /opt/myapp/bin/server

# 2. Tenta executar o script em foreground e observa o bloqueio
/opt/myapp/bin/server
# Será interrompido por violação; anote o PID ou verifique os logs
ausearch -m avc -ts recent

# 3. Gera um módulo de política a partir dos logs
# Primeiro, filtra os eventos relevantes e cria um arquivo .te (type enforcement)
ausearch -m avc -ts recent | audit2allow -m myapp > myapp.te

# Exibe o conteúdo do arquivo gerado para revisão
cat myapp.te

module myapp 1.0;

require {
        type default_t;
        type unconfined_t;
        type var_log_t;
        class file { append create getattr open read write };
}

#============= unconfined_t ==============
allow unconfined_t default_t:file { create append getattr open read write };
allow unconfined_t var_log_t:file { append create open read write };

O arquivo myapp.te contém as regras que o audit2allow deduziu. Antes de prosseguir, revise‑o cuidadosamente — audit2allow é uma ferramenta de sugestão, não de decisão final. Em muitos casos, ele pode sugerir permissões muito amplas. Após a revisão, compilamos e carregamos o módulo:

# 4. Compila o módulo e gera o pacote de política (.pp)
checkmodule -M -m -o myapp.mod myapp.te
semodule_package -o myapp.pp -m myapp.mod

# 5. Carrega o módulo no kernel
semodule -i myapp.pp

# 6. Verifica se o módulo foi carregado
semodule -l | grep myapp

myapp

Agora, ao executar /opt/myapp/bin/server &, o script consegue gravar em /var/log/myapp/server.log sem bloqueios. Este fluxo é exatamente o que aplicamos em ambientes controlados na JRT Technology Solutions quando um fornecedor entrega software sem suporte a SELinux — criamos políticas sob medida que permitem a operação sem jamais desabilitar o MAC.

6. AppArmor: Perfis, Modos e Ferramentas no Ubuntu Server 24.04

Passando para o ecossistema Debian/Ubuntu, o AppArmor é carregado e ativo por padrão. Para verificar, utilizamos aa-status, que exibe o número de perfis carregados, quantos estão em modo enforce e em modo complain, além dos processos atualmente confinados. Os perfis AppArmor residem em /etc/apparmor.d/ e são escritos em uma sintaxe declarativa intuitiva. Cada perfil é nomeado pelo caminho absoluto do binário, com barras substituídas por pontos (ex.: /usr/sbin/nginx vira usr.sbin.nginx). O diretório /etc/apparmor.d/abstractions/ contém regras reutilizáveis (como acesso a bibliotecas, certificados, DNS) que podem ser incluídas com #include <abstractions/base>.

Modos de operação do AppArmor: um perfil em enforce aplica as regras e bloqueia ações não permitidas, gerando entradas em /var/log/syslog e dmesg. No modo complain, o perfil apenas registra o que teria sido bloqueado, sem interferir na execução — ideal para criar novos perfis. Ferramentas do pacote apparmor-utils simplificam a criação e manutenção: aa-genprof inicia um assistente interativo para gerar um perfil a partir da execução monitorada de um programa; aa-logprof varre os logs e sugere adições a um perfil existente; aa-complain e aa-enforce alternam o modo de um perfil; apparmor_parser carrega/recarrega perfis no kernel.

A principal vantagem do AppArmor sobre o SELinux para muitos administradores é a simplicidade: o perfil é um arquivo de texto legível, e o path‑based matching elimina a necessidade de rotular todo o sistema de arquivos. Por outro lado, ele não oferece controle tão fino sobre IPC, sockets ou transições de domínio, e pode ser contornado via mount namespaces ou symbolic links se o perfil não for cuidadoso. Ainda assim, para a maioria das implantações web, ele fornece uma barreira eficaz e de fácil manutenção. Nos nossos serviços gerenciados de infraestrutura, costumamos recomendar AppArmor para times menores que precisam de confinamento rápido, e SELinux para organizações sujeitas a regulamentações rigorosas que exigem o modelo de labeling.

7. Passo a Passo — Criando um Perfil AppArmor para uma Aplicação Customizada no Ubuntu

Vamos criar um perfil para a mesma aplicação fictícia /opt/myapp/bin/server no Ubuntu Server 24.04. A instalação dos utilitários é o primeiro passo. Em seguida, usaremos o aa-genprof para gerar um esqueleto inicial enquanto exercitamos o programa. Este método interativo é excelente para aprendizado, mas em produção é comum escrever o perfil manualmente e depois refiná‑lo com aa-logprof.

1. Instale os pacotes e prepare o ambiente.

   apt update
   apt install -y apparmor-utils auditd
   
   # Cria os mesmos diretórios e script do exemplo anterior
   mkdir -p /opt/myapp/bin /var/log/myapp
   cat > /opt/myapp/bin/server << 'EOF'
   #!/bin/bash
   echo "Server started at $(date)" >> /var/log/myapp/server.log
   while true; do sleep 60; done
   EOF
   chmod +x /opt/myapp/bin/server

2. Inicie o gerador de perfil interativo. O aa-genprof vai pausar e pedir que, em outro terminal, você execute o programa normalmente. Ele monitorará as chamadas de sistema e, ao final, exibirá uma série de perguntas.

   aa-genprof /opt/myapp/bin/server

   A ferramenta exibirá uma tela pedindo para iniciar a aplicação. Em outro terminal, execute:

   /opt/myapp/bin/server &
   # Deixe rodando alguns segundos, depois volte ao terminal do aa-genprof e pressione 'S' para scanear

3. Responda às perguntas do assistente. O aa-genprof apresentará recursos acessados (arquivos, bibliotecas, pipes) e perguntará se devem ser permitidos (Allow), negados (Deny) ou se a regra deve ser globada (Glob). Para um perfil restritivo, escolha “Allow” para /var/log/myapp/server.log (com permissão w) e “Deny” para acessos desnecessários. Ao final, ele salvará o perfil em /etc/apparmor.d/opt.myapp.bin.server e o carregará em modo enforce.
4. Verifique o perfil gerado e o status do AppArmor.

   # Exibe o perfil criado
   cat /etc/apparmor.d/opt.myapp.bin.server

   # Last Modified: Sat Jul 25 15:00:00 2026
   abi <abi/3.0>,
   include <tunables/global>
   
   /opt/myapp/bin/server {
     include <abstractions/base>
     include <abstractions/bash>
   
     /opt/myapp/bin/server r,
     /var/log/myapp/server.log w,
     /dev/tty rw,
     ...
   }

   O perfil inclui abstrações essenciais e permite leitura do próprio binário (r) e escrita no log (w). Dependendo da aplicação, podem aparecer entradas para bibliotecas dinâmicas ou /proc.

5. Confira que o perfil está em modo enforce.

   aa-status | grep -A2 myapp

   1 profiles are in enforce mode.
      /opt/myapp/bin/server

Caso o perfil precise de ajustes posteriores, execute aa-logprof periodicamente: ele lê os eventos de negação do log do sistema e sugere atualizações, mantendo seu perfil sempre aderente ao comportamento real da aplicação.

8. Verificando a Instalação / Testando a Configuração

Para confirmar que o SELinux e o AppArmor estão operando como esperado, execute os seguintes blocos de verificação em seus respectivos sistemas. Em qualquer dúvida sobre a saída, os treinamentos da JRT Technology Solutions abordam cada linha em detalhes práticos.

Verificação SELinux (Rocky Linux 9)

# Modo atual e política
getenforce
sestatus | grep -E "^Loaded|^Current|^Mode"

# Lista de módulos carregados (verifique se 'myapp' aparece)
semodule -l | head -5

# Contexto do diretório web personalizado
ls -Zd /web

# Últimos 5 AVCs (devem estar vazios ou conter apenas eventos antigos)
ausearch -m avc -ts today | tail -5

# Teste funcional: acesso HTTP ao diretório customizado
curl -s http://localhost | head -1

Enforcing
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
myapp
unconfined_u:object_r:httpd_sys_content_t:s0 /web
<h1>SELinux Lab - JRT Technology Solutions</h1>

Verificação AppArmor (Ubuntu Server 24.04)

# Status geral do AppArmor
aa-status

# Perfil específico da nossa aplicação (modo e nome)
aa-status | grep "/opt/myapp"

# Verifica se o processo está confinado (substitua pelo PID real)
ps auxZ | grep server

# Testa bloqueio: tenta escrever em um arquivo não permitido (como root)
sudo /opt/myapp/bin/server -c "echo test > /etc/forbidden.txt"
dmesg | grep -i apparmor | tail -3

apparmor module is loaded.
1 profiles are loaded.
1 profiles are in enforce mode.
   /opt/myapp/bin/server
[ 1234.567890] audit: type=1400 audit(...): apparmor="DENIED" operation="open" profile="/opt/myapp/bin/server" name="/etc/forbidden.txt" pid=9999 comm="server" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0

Essas verificações comprovam que ambos os sistemas estão ativos, aplicando políticas e capazes de registrar violações — o estado mínimo esperado para um ambiente produtivo seguro.

9. Erros Comuns e Como Resolver

• SELinux bloqueia serviço legítimo após atualização de pacote.
  Causa: A atualização pode ter sobrescrito contextos de arquivo ou introduzido novos binários sem rotulagem adequada.
  Sintoma: Serviço falha ao iniciar com mensagens “Permission denied” mesmo com DAC correto; logs AVC aparecem com denied.
  Solução: Execute restorecon -Rv /caminho/do/serviço para reaplicar os contextos padrão. Se o problema persistir, use sealert -a /var/log/audit/audit.log para identificar a transição exata e, se necessário, crie um módulo com audit2allow ou ajuste um booleano. Em casos emergenciais, coloque o domínio em permissivo com semanage permissive -a dominio_t enquanto corrige a política, sem desabilitar o SELinux globalmente.
• AppArmor impede inicialização de container Docker após reboot.
  Causa: O perfil AppArmor do Docker (docker-default) ou um perfil personalizado pode ser muito restritivo para novos fluxos de rede ou montagens de volume.
  Sintoma: Container falha com “Permission denied” ao tentar bind mount ou acessar sockets. dmesg mostra apparmor="DENIED".
  Solução: Coloque o perfil problemático em modo complain temporariamente com aa-complain /etc/apparmor.d/<perfil>, reproduza a falha, execute aa-logprof para gerar as regras adicionais e então reative o modo enforce com aa-enforce <perfil>. Nunca remova o perfil Docker padrão sem uma alternativa.
• Contexto SELinux perdido após mover arquivos com mv (em vez de cp).
  Causa: O comando mv preserva o contexto original do arquivo/diretório, que pode não ser adequado ao novo local.
  Sintoma: Arquivos movidos para /var/www/html exibem tipo default_t ou admin_home_t e geram AVC denied.
  Solução: Sempre utilize cp seguido de rm quando a preservação de contexto não for desejada, ou execute restorecon -Rv /destino após a movimentação. Para evitar recorrências, crie uma regra semanage fcontext como demonstramos na seção 3.
• Perfil AppArmor não carrega após modificação manual.
  Causa: Erro de sintaxe no arquivo de perfil ou perfil com encoding incorreto.
  Sintoma: apparmor_parser -r perfil retorna erro, e aa-status não lista o perfil.
  Solução: Verifique a sintaxe com apparmor_parser -Q perfil. Erros comuns incluem falta de vírgula no final das linhas de regra ou referência a caminhos que não existem. Após corrigir, recarregue com apparmor_parser -r perfil e confirme com aa-status.

10. Boas Práticas e Dicas Avançadas

Em ambientes gerenciados com automação (Ansible, Puppet, Chef), trate as configurações de MAC como código. Armazene os arquivos .te e .pp do SELinux em um repositório Git, versionando junto com os playbooks. Para AppArmor, mantenha os perfis sob /etc/apparmor.d/ rastreáveis. Nossos especialistas utilizam diariamente pipelines CI/CD que testam as políticas em containers efêmeros antes do deploy em produção, garantindo que nenhum booleano ou perfil cause regressão. Outra prática recomendada é integrar os logs de AVC e AppArmor ao seu SIEM (ELK, Splunk, Wazuh) com alertas para qualquer denied inesperado — isso permite detectar tentativas de ataque ou configurações incorretas em tempo real.

Para SELinux em particular, evite a tentação de criar módulos permissivos para domínios inteiros permanentemente. Use booleanos sempre que possível; eles são suportados e mantidos pela distribuição, enquanto módulos customizados precisam ser revalidados a cada grande atualização do sistema operacional. Quando migrar de uma versão maior do RHEL (ex.: 8 para 9), verifique a compatibilidade dos seus módulos usando semodule -l e o utilitário selinux-policy-migrate, quando disponível.

No universo AppArmor, explore as abstrações: em vez de replicar regras de acesso a bibliotecas ou certificados, inclua as abstrações já existentes em /etc/apparmor.d/abstractions/. Isso reduz o tamanho do perfil e facilita manutenção futura. Para aplicações containerizadas, o Docker e o Podman possuem integração nativa: o Docker gera dinamicamente um perfil docker-default, e você pode associar perfis personalizados com a opção --security-opt apparmor=meu-perfil. Teste sempre com aa-logprof após qualquer alteração no fluxo do container.

Por fim, lembre‑se de que o MAC não substitui o DAC, e sim o complementa. Mantenhas as permissões Unix mínimas rigorosas e aplique o MAC como a segunda camada. Um sistema com chmod 777 generalizado ainda estará vulnerável, independentemente do SELinux ou AppArmor, pois as chamadas de sistema autorizadas pelo DAC podem passar pelo MAC se houver regras permissivas. A defesa em profundidade exige que cada camada seja configurada com o menor privilégio possível.

Resumo da Aula 22

Nesta aula extensa e prática, nós desconstruímos o Controle de Acesso Obrigatório em Linux por meio de seus dois expoentes: SELinux e AppArmor. Começamos estabelecendo a diferença fundamental entre DAC e MAC, e como o kernel implementa ganchos LSM para que políticas centralizadas prevaleçam sobre permissões discricionárias. Exploramos a arquitetura de labeling do SELinux — seus contextos, domínios, tipos e booleanos — e executamos um laboratório completo de diagnóstico e correção de violações no Rocky Linux 9, culminando na criação de um módulo de política personalizado com audit2allow. Em seguida, mergulhamos no AppArmor do Ubuntu Server 24.04, detalhando a estrutura de perfis path‑based, os modos enforce/complain e a geração interativa de perfis com aa-genprof. Aprendemos a verificar o estado de ambos os sistemas, a interpretar logs de negação e a resolver os erros mais comuns sem jamais desabilitar a proteção.

As tabelas abaixo resumem os principais comandos e flags que você deve ter à mão no dia a dia de administração de sistemas Linux.