Nesta aula, mergulharemos nos principais mecanismos de segurança disponíveis em distribuições Linux, especialmente Ubuntu. Compreender permissões, sistemas de controle de acesso obrigatório (MAC) como SELinux e AppArmor, e auditoria com auditd é essencial para qualquer profissional de segurança ou administrador de sistemas. Vamos explorar como cada um funciona, como configurá-los e como eles se complementam para criar uma defesa em profundidade.

Começaremos com o básico: permissões de arquivos, que são a primeira linha de defesa. Em seguida, avançaremos para os módulos de segurança do kernel que impõem políticas mais rígidas. Por fim, veremos como auditar eventos para detectar e investigar incidentes.

Permissions

As permissões de arquivos no Linux são um dos conceitos fundamentais de segurança. Elas controlam quem pode ler, escrever ou executar um arquivo ou diretório. No Ubuntu, como em qualquer sistema Unix, cada arquivo possui um proprietário, um grupo e um conjunto de permissões para três categorias de usuários: proprietário (u), grupo (g) e outros (o). As permissões são representadas por letras (r, w, x) ou números octais (4, 2, 1).

Entender e configurar permissões corretamente é crucial para evitar que usuários não autorizados acessem dados sensíveis. Por exemplo, um arquivo de configuração com senhas deve ser legível apenas pelo proprietário. Vamos ver como visualizar e alterar permissões usando comandos como ls -l, chmod e chown.

# Exibir permissões de um arquivo
ls -l /etc/shadow
# Saída exemplo: -rw-r----- 1 root shadow 1234 Jan 1 00:00 /etc/shadow

# Alterar permissões para leitura e escrita apenas para o proprietário
chmod 600 arquivo_secreto.txt

# Alterar o proprietário de um arquivo
chown alice:financeiro relatorio.txt

Além das permissões básicas, existem atributos especiais como SUID, SGID e sticky bit, que podem representar riscos de segurança se mal configurados. O SUID permite que um arquivo seja executado com os privilégios do proprietário, o que pode ser explorado. Portanto, é importante auditar regularmente esses bits em todo o sistema.

SELinux

SELinux (Security-Enhanced Linux) é um módulo de segurança do kernel que implementa controle de acesso obrigatório (MAC). Diferente das permissões tradicionais (DAC), o SELinux define políticas que restringem processos e usuários, mesmo que eles tenham permissões de acesso. Ele rotula cada arquivo, processo, diretório e até mesmo porta de rede com um contexto de segurança, e as regras determinam quais interações são permitidas.

No Ubuntu, o SELinux não é usado por padrão; a distribuição adota o AppArmor. No entanto, SELinux é padrão no Red Hat, Fedora e CentOS. Se você administra sistemas heterogêneos, é essencial entender SELinux. Sua configuração é feita em arquivos de política, e o comando getenforce mostra o estado atual (Enforcing, Permissive, Disabled).

# Verificar status do SELinux
sestatus
# Saída exemplo: SELinux status: enabled, mode: enforcing

# Mudar para modo permissivo (temporário)
setenforce 0

# Consultar contextos de arquivos
ls -Z /var/www/html/index.html

Para administradores, é vital saber como criar e modificar políticas, bem como solucionar problemas de acesso negado. Arquivos de log em /var/log/audit/audit.log registram tentativas negadas. Ferramentas como audit2why ajudam a interpretar esses logs.

AppArmor

AppArmor é um módulo de segurança do kernel que também implementa MAC, mas de forma mais simples e focada em caminhos de arquivos. Ele é o padrão no Ubuntu e em outras distribuições como SUSE. AppArmor confina programas a um conjunto de recursos (arquivos, redes, capabilities) definidos em perfis. Cada perfil especifica o que o programa pode acessar, bloqueando o resto por padrão.

Os perfis do AppArmor ficam em /etc/apparmor.d/. Eles podem estar em modo reclamar (complain) ou reforcer (enforce). No modo reclamar, as violações são registradas, mas não bloqueadas, útil para testar. O comando aa-status mostra o status dos perfis carregados.

# Ver status do AppArmor
aa-status

# Carregar um perfil em modo enforce
aa-enforce /etc/apparmor.d/usr.bin.nginx

# Colocar em modo complain
aa-complain /etc/apparmor.d/usr.bin.nginx

Para criar um perfil, pode-se usar a ferramenta aa-genprof ou escrever manualmente. Um exemplo simples de perfil para um script:

# Perfil para /usr/local/bin/meuscript
#include <tunables/global>

/usr/local/bin/meuscript flags=(complain) {
  #include <abstractions/base>

  /etc/meuapp/config r,
  /var/log/meuapp/ rw,
  network inet tcp,
}

AppArmor é mais fácil de gerenciar que SELinux para iniciantes, mas menos flexível em ambientes complexos. No Ubuntu, muitos pacotes já vêm com perfis prontos, e você pode verificar se um processo está confinado com aa-status.

Auditd

O auditd é o daemon de auditoria do Linux, responsável por registrar eventos de segurança em um log detalhado. Ele pode monitorar chamadas de sistema, acessos a arquivos, mudanças de configuração e muito mais. Isso é essencial para detecção de intrusões e conformidade com normas como PCI-DSS.

O auditd é configurado através de regras no arquivo /etc/audit/rules.d/audit.rules ou com o utilitário auditctl. As regras definem quais eventos devem ser capturados. Por exemplo, você pode auditar todas as tentativas de leitura do arquivo de senhas.

# Instalar auditd no Ubuntu
sudo apt install auditd

# Adicionar uma regra para monitorar /etc/shadow
auditctl -w /etc/shadow -p wa -k shadow_changes

# Listar regras ativas
auditctl -l

# Ver logs de auditoria
aureport --auid

Os logs são armazenados em /var/log/audit/audit.log e podem ser consultados com ferramentas como ausearch e aureport. A análise desses logs pode revelar tentativas de acesso não autorizado, mudanças suspeitas em arquivos críticos e outros indicadores de comprometimento.

É importante configurar regras de auditoria com cuidado, pois elas podem gerar grandes volumes de log e afetar o desempenho. Priorize monitorar arquivos sensíveis, execuções de comandos privilegiados e alterações de permissões.

Boas Práticas e Observações Finais

A segurança de um sistema Linux não depende de um único mecanismo, mas da combinação de todos eles. Use permissões para controle básico, AppArmor (ou SELinux) para confinamento de aplicações e auditd para monitoramento contínuo. Mantenha o sistema atualizado, remova serviços desnecessários e aplique o princípio do menor privilégio em todos os níveis.

Teste sempre as políticas em um ambiente de homologação antes de aplicá-las em produção. Monitore os logs regularmente e integre-os a um SIEM se possível. Lembre-se: segurança é um processo contínuo, não um estado final.

Referências

Exercícios

  1. Exercício 1: Explique a diferença entre DAC (Discretionary Access Control) e MAC (Mandatory Access Control). Dê um exemplo de cada no contexto do Ubuntu.

    2. ✓ Resposta: DAC é o controle de acesso discricionário, onde o proprietário do recurso decide quem pode acessá-lo. Exemplo: permissões de arquivo com chmod (o dono define). MAC é obrigatório, onde o sistema impõe políticas independentes do usuário. Exemplo: AppArmor confina um processo a determinados arquivos, mesmo que o usuário tenha permissões de leitura.
  2. Exercício 2: Qual comando você usaria para dar permissão de execução a todos os usuários em um script chamado backup.sh? Escreva o comando e explique o que ele faz.

    3. ✓ Resposta: O comando é chmod a+x backup.sh. Ele adiciona (+) a permissão de execução (x) para todos (a = user, group, others).
  3. Exercício 3: No SELinux, qual é a diferença entre os modos Enforcing e Permissive? Como você alterna entre eles?

    4. ✓ Resposta: Enforcing: as políticas são aplicadas e violações são bloqueadas e registradas. Permissive: as violações são registradas, mas não bloqueadas. Para alternar temporariamente, use setenforce 0 (permissivo) ou setenforce 1 (enforcing). Para persistir, edite /etc/selinux/config.
  4. Exercício 4: Crie um perfil AppArmor simples para o programa /usr/bin/meuapp que permita ler o arquivo /etc/meuapp.conf e escrever em /var/log/meuapp.log. Mostre o conteúdo do perfil.

    5. ✓ Resposta: 
    # Perfil para /usr/bin/meuapp
#include <tunables/global>

/usr/bin/meuapp {
  #include <abstractions/base>

  /etc/meuapp.conf r,
  /var/log/meuapp.log w,
}
  5. Exercício 5: Suponha que você queira auditar todas as tentativas de abertura do arquivo /etc/passwd. Escreva a regra do auditd para isso e explique como você verificaria os logs.

    6. ✓ Resposta: Regra: auditctl -w /etc/passwd -p r -k passwd_read (monitora leitura). Para ver os logs: ausearch -k passwd_read ou grep passwd_read /var/log/audit/audit.log. Use aureport para resumos.