Redes e Segurança

Segurança com SELinux e AppArmor: políticas e contextos

• 5 min de leitura

Segurança com SELinux e AppArmor: políticas e contextos
No modelo DAC tradicional (Linux padrão), o proprietário de um arquivo decide quem pode acessá-lo. O MAC (Mandatory Access Control) impõe regras globais do sistema que nem mesmo o root pode ignorar. Enquanto DAC controla "quem" acessa, MAC controla "o que" pode acessar "o quê", baseado em políticas centralizadas.

Segurança com SELinux e AppArmor: políticas e contextos

1. Introdução aos Sistemas de Controle de Acesso Mandatório (MAC)

1.1. Diferença entre DAC (Discretionary Access Control) e MAC

No modelo DAC tradicional (Linux padrão), o proprietário de um arquivo decide quem pode acessá-lo. O MAC (Mandatory Access Control) impõe regras globais do sistema que nem mesmo o root pode ignorar. Enquanto DAC controla "quem" acessa, MAC controla "o que" pode acessar "o quê", baseado em políticas centralizadas.

1.2. Visão geral do SELinux e AppArmor: origens e filosofias

SELinux (Security-Enhanced Linux) nasceu na NSA e integra-se ao kernel via LSM (Linux Security Module). Usa etiquetas em todos os objetos (arquivos, processos, portas) e define regras granulares. AppArmor, desenvolvido pela Novell e Canonical, foca em perfis baseados em caminhos de arquivos, sendo mais simples de gerenciar.

1.3. Quando usar cada um: cenários típicos

  • SELinux: Preferido em RHEL/CentOS/Fedora, ambientes governamentais e servidores que exigem políticas MLS (Multi-Level Security).
  • AppArmor: Padrão no Ubuntu/Debian/SUSE, ideal para servidores web, containers e ambientes que priorizam facilidade de configuração.

2. SELinux: Arquitetura e Modos de Operação

2.1. Modos: Enforcing, Permissive e Disabled

Verifique o modo atual:

getenforce

Altere temporariamente:

setenforce 0   # Permissive
setenforce 1   # Enforcing

Para alterar permanentemente, edite /etc/selinux/config:

SELINUX=enforcing

2.2. Políticas: Targeted, MLS e MCS

  • Targeted: Padrão, protege serviços específicos (httpd, sshd).
  • MLS: Controle multinível (governo, militar).
  • MCS: Similar ao MLS, mas para ambientes de nuvem/containers.

Verifique a política atual:

sestatus | grep "Loaded policy"

2.3. Contextos de segurança: exemplos práticos

Cada arquivo/processo tem um contexto no formato usuário:papel:tipo:nível:

ls -Z /var/www/html/index.html
# system_u:object_r:httpd_sys_content_t:s0

Para um processo:

ps -Z | grep httpd
# system_u:system_r:httpd_t:s0

3. Trabalhando com Políticas SELinux

3.1. Gerenciamento com ferramentas

Liste todos os contextos de arquivos:

semanage fcontext -l

Consulte permissões de tipo:

sesearch -A -s httpd_t -t httpd_sys_content_t

Liste booleans:

getsebool -a

3.2. Criação de módulos com audit2allow

Quando um acesso é negado, gere um módulo personalizado:

ausearch -m avc -ts recent | audit2allow -M meu_modulo
semodule -i meu_modulo.pp

3.3. Booleans SELinux

Ative um boolean sem recompilar:

setsebool -P httpd_enable_homedirs on

4. AppArmor: Perfis e Modos de Confinamento

4.1. Modos: Enforce, Complain e Disabled

Verifique status:

aa-status

Coloque um perfil em modo complain (apenas logs):

aa-complain /usr/sbin/nginx

Ative enforce:

aa-enforce /usr/sbin/nginx

4.2. Estrutura de um perfil

Exemplo de perfil para /usr/bin/myapp:

# /etc/apparmor.d/usr.bin.myapp
#include <tunables/global>

/usr/bin/myapp {
  #include <abstractions/base>
  /etc/myapp/config r,
  /var/log/myapp/* w,
  /tmp/myapp_* rw,
  network inet tcp,
}

4.3. Ferramentas práticas

Gere um perfil automaticamente:

aa-genprof /usr/bin/myapp

Analise logs de negação:

aa-logprof

Verifique processos sem perfil:

aa-unconfined

5. Contextos e Etiquetagem de Arquivos e Processos

5.1. SELinux: etiquetagem

Altere contexto manualmente:

chcon -t httpd_sys_content_t /var/www/html/index.html

Restaure o contexto padrão:

restorecon -Rv /var/www/html

Corrija todo o sistema:

fixfiles -R onboot

5.2. AppArmor: anexação de perfis

Perfis são anexados por caminho de executável. Para processos filho, use:

/usr/bin/meuapp {
  /usr/bin/meuapp_child px,  # perfil filho separado
}

5.3. Verificação de contexto

SELinux:

ls -Z /etc/shadow
ps -Z -u root

AppArmor:

cat /proc/1/attr/current
aa-unconfined

6. Depuração e Resolução de Problemas Comuns

6.1. SELinux: logs AVC

Consulte negações recentes:

ausearch -m avc -ts today

Obtenha explicação:

ausearch -m avc -ts today | audit2why

Via journalctl:

journalctl -t audit | grep AVC

6.2. AppArmor: análise de negações

aa-notify -s
dmesg | grep apparmor

6.3. Estratégias de troubleshooting

  1. Coloque o serviço em modo permissivo/complain.
  2. Replique o cenário que falha.
  3. Analise logs e crie exceções.
  4. Teste em enforce.

7. Integração com Serviços Comuns

7.1. SELinux para Samba, NFS e SSH

Samba:

setsebool -P samba_export_all_rw on
chcon -t samba_share_t /caminho/compartilhado

NFS:

setsebool -P nfs_export_all_rw on

SSH:

setsebool -P ssh_chroot_rw on

7.2. AppArmor: perfis prontos

Ubuntu já inclui perfis para serviços comuns:

ls /etc/apparmor.d/ | grep -E "nginx|mysql|ssh"

Customize copiando o perfil existente.

7.3. Teste de segurança

Simule acessos não autorizados e verifique logs:

sudo -u ninguem cat /etc/shadow
ausearch -m avc -ts recent | tail -5

8. Boas Práticas e Hardening com MAC

8.1. Migração gradual

  1. Ative modo permissivo/complain por 48h.
  2. Analise logs e ajuste políticas.
  3. Ative enforce gradualmente por serviço.

8.2. Automatização de políticas

Script para SELinux:

#!/bin/bash
semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"
restorecon -Rv /web
setsebool -P httpd_can_network_connect on

8.3. Checklist pós-configuração

  • [ ] getenforce retorna "Enforcing"
  • [ ] aa-status mostra perfis ativos
  • [ ] Nenhum AVC crítico no ausearch
  • [ ] Serviços testados com acesso negado
  • [ ] Políticas versionadas em Git

Consulte CIS Benchmarks para hardening específico de distribuição.

Referências

💬 Comentários
Mais em Redes e Segurança