O documento fornece uma introdução ao Security Enhanced Linux (SELinux), descrevendo seus principais conceitos como o controle de acesso obrigatório, confinamento de processos em "sandboxs" e políticas de segurança focadas. Explica como o SELinux implementa controles de acesso mais finos do que o padrão Discretionary Access Control (DAC) do Linux e como foi desenvolvido originalmente pela NSA para aumentar a segurança do sistema.

1. DESMITIFICANDO
Security Enhanced
Linux
1o. S.G.S.L / 5o. F.G.S.L.
Ulisses Castro
por

2. QUEM SOU ?
• Consultor em Infra-estrutura e Segurança
• Projetos em instituições financeiras
• Cursos de segurança (governo/empresas
privadas)
• Mantenedor Debian (pacote selinux-basics)
• Voluntário projeto ASDR (OWASP)
• Colaborador LPI Exam Developer (LPIC-3)
• Certificado LPIC-2
• CEH - Certified Ethical Hacker
• Serviços (Pentest e Hardening)
• Pai e marido nas horas vagas! :-)

3. PORQUE DESMITIFICANDO ?
• Fedora Core 2 (2004)
• SELinux “ativado” por padrão
• Terror e Pânico (forums, irc, etc)
• Marcou de maneira negativa

4. CONTROLES DE ACESSO
COMUNS
• Discretionary Access Control (DAC)
• Mandatory Access Control (MAC)

5. DAC - CONCEITOS
• SETUID/SETGID = vunerabilidade
• Acesso baseado somente em (uid/gid)
• Política padrão muito liberal
• Somente dois tipos de usuário: usuário e
administrador
• Sem condições de aplicar o “menor
privilégio”

6. DAC
KERNEL

7. MAC - CONCEITOS
• Difícil de gerenciar/administrar
• Objetos são abstraídos em duas classes:
• Subjects: usuário e processos
• Objects: arquivos
• Controle fino/granular em relação ao DAC
• Restringe acesso através das “syscalls”
• Política de “Sandboxes”

8. MAC
POLÍTICAS
KERNEL

9. DAC

10. MAC

11. SECURITY ENHANCED LINUX
• Criado pela NSA(National Security Agency)
• Tornou-se (GPL) software livre em 2000
• Proteção pró-ativa contra bugs/zero days
• Patches compilados “built in” no Kernel
• A checagem MAC ocorre APÓS a DAC
• Nega por padrão quaquer interação entre
usuários/processos e arquivos
• AVC - Access Vetor Cache

12. OBJETIVOS
• Isolamento das aplicações (confinamento)
• Fluxo de informações
• Confidencialidade
• Integridade
• Auto-proteção
• Política do menor privilégio
• Modular (políticas)

13. ENTENDENDO CONTEXTOS
• 3 Modos de funcionamento
• Enforcing/Permissive/Disabled
• Processos e arquivos tem contextos de
seguranças aplicados. Ex:
root:system_r:httpd_t:s0
Sintaxe: user:role:type:level
• type - usado para implementar (Type
Enforcement) campo chave para o
confinamento
• Outros são para implementar RBAC e MLS

14. TYPE ENFORCEMENT
• Baseado em uma única propriedade (type)
• type quando aplicado em um arquivo = tipo,
quando aplicado à um processo = domínio
• types são definidos em processos e
recursos
• Processos do Apache (httpd_t)
• Os acessos são permitidos entre os
“types”
• Ex: httpd_t pode ler httpd_sys_content

15. POLÍTICA (TARGETED)
• Protege contra vulnerabilidades em
processos e serviços
• No Debian Etch existem mais de 150
políticas prontas para uso
• Apache, Bind, Squid, Dhcp, Ftp ...
• Cada processo é jogado dentro da
“sandbox” :-)
• Todos os outros ficam de fora -
unconfined_t
•A criação de políticas não é tão
complexa (audit2allow, audit2why)

16. ?

17. REFERÊNCIAS
http://selinuxproject.org
http://selinuxnews.org/planet
http://wiki.debian.org/SELinux
http://www.nsa.gov/selinux/
http://fedoraproject.org/wiki/SELinux
http://jczucco.googlepages.com/Trabalho_Jeronimo_pos.html
http://www.redhatmagazine.com
http://selinux-symposium.org
Projeto ASDR:
https://www.owasp.org/index.php/ASDR_TOC_Attacks
Instalação SELinux Debian:
http://ulissescastro.wordpress.com

18. OBRIGADO!
e-mail:
uss.thebug@gmail.com
blog:
http://ulissescastro.wordpress.com