O estudo comparativo a seguir, é um trabalho relativo a disciplina Administração Unix-Like do curso de Pós Graduação em Administração e Segurança de Sistemas Computacional, este comparativo visa apresentar as diferenças básicas entre as ferramentas, com uma visão superficial de sua arquitetura.
Você gostou do post, e quer mais?
Me paga um café! :) PIX consultoria@carlosdelfino.eti.br
Curta o post no final da página, use o Disqus, compartilhe em sua rede social. Isso me ajuda e motiva
Obrigado.
O estudo comparativo a seguir, é um trabalho relativo a disciplina Administração Unix-Like do curso de Pós Graduação em Administração e Segurança de Sistemas Computacional, este comparativo visa apresentar as diferenças básicas entre as ferramentas, com uma visão superficial de sua arquitetura.
Introdução
Apresentamos neste artigo duas ferramentas Linux que visam reduzir a zero o ataque ao sistema operacional por suas diversas opções de entrada e saída, controlando assim aplicações que fazem uso dos recursos do sistema operacional.
O conceito de Estruturas de Segurança envolve diversas ferramentas, porém iremos comparar apenas duas delas SELinux (Secure-Enhanced Linux) e AppArmor (Application Armor) que sem dúvida são as mais utilizadas e discutidas atualmente.
Revisão Bibliográfica
Visando compreender o vocabulário usado neste artigo, e facilitando a leitura não somente por especialistas no campo de segurança, mas buscando auxiliar profissionais dos setores de tomada de decisão das mais diversas modalidade de empresas, abaixo está listado alguns termos que serão comumente vistos aqui.
DAC
Sistema de permissões padrão do Linux. (Discretionary Access Control, ou Controle Discricionário de Acesso). Nativo no Linux e representado em especial pelo comando chmod que altera os direitos e acesso para os três níveis de uso do arquivo, Usuário, Grupos e Outros.
LSM
Linux Security Module, uma infraestrutura que estabelece a arquitetura de módulos usadas para carregar novos serviços de segurança.
MAC
Mandatory Access Control, Controle obrigatório de Acesso.
NSA
National Security Agency - Agencia Nacional de Segurança, organização Norte Americana de Defesa Nacional.
SElinux teve sua origem na pesquisa realizada pela NSA juntamente com as empresas SCC (Secure Computing Corporation) e MITRE (MITRE COMPORTATION, uma organização sem fins lucrativos.), com o nome “Projeto Extravaganza” no inicio dos anos 90, conforme o tutorial [IBM-Part1-SELinux], nesta época não existia o Linux, e o projeto era destinado ao Sistema Operacionais de nome Mach em uma versão conhecida como DTMach criado para ambientes distribuídos, tendo em seguida como foco de desenvolvimento o sistema DTOS, era desenvolvido no National Information Assurance Research Laboratory, pelo grupo Truested Systems Research group [NCSA-TSRG], com a entrada da Universidade de Utah foi portado para o sistema operacional Fluke, com o nome de Flux. Em paralelo o NSA adotou a políticas de segurança mais dinâmicas e finalmente em 2000 assumiu o nome SELinux sendo portado e disponibilizado no Linux no Kernel 2.2.
Em paralelo AppArmor teve seu desenvolvimento iniciado em 1998 para o Immunix uma versão segura do linux, nesta época conhecido como SubDomain e era produzido pela empresa Wirex, conforme [AppArmor-History], contribuindo assim com a criação do LSM. Em 2005 Novell adquiriu o Immunix, renomeando SubDomain para AppArmor, reescrevendo todo o código readequando ao Kernel do Linux. Em 2009 AppArmor foi liberado como um módulo do kernel linux mais integrado ao LSM e finalmente em 2010 se tornou um módulo oficial do kernel 2.6.36.
Aspectos de Segurança (Sobre os Softwares)
O SELinux, conforme [WorldLibrary-AppArmor], usa iNodes o que lhe dá
maior segurança, mesmo com a criação de hard-links, neste caso negando o acesso ao arquivo com base no novo iNode. Já o AppArmor tem seu profiles baseados no path do arquivo, sendo sujeito a falhas caso sejam criados links.
Comparativo
A tabela abaixo foi baseada em outra disponível em [suse-selinux-comparison], onde a empresa Novell responsável pela distribuição de mesmo nome, apresenta as diferenças entre as estruturas de segurança AppArmor e SELinux, considerando esta distribuição.
AppArmor
SELinux
Tipo de segurança
Sistema baseado em Pathname (caminho do arquivo) e não requer "Etiquetas" ou "Reetiquetamento" do sistema de arquivos.
Quando desenvolvendo perfis (Profiles) de forma incremental, há muito menos razões para modificar outros perfis, porque todos os profiles simplesmente referem se ao caminho usado
"Caminhos de Arquivos" (Pathnames) são fáceis de entender e auditar.
Anexa etiquetas a todos os arquivos e processos
Etiquetas identificam os canais de comunicação, para adicionar novos perfis (profiles) pode requerer a alteração de perfis existentes para dividir canais de comunicação, tornando o desenvolvimento de politicas difícil
Nem todas as aplicações preservam as etiquetas
Consequências
Ferramentas automatizada
Fácil integração na plataforma Novel
Manutenção Difícil
Baixa taxa de adoção
Fácil de usar
Politicas auditáveis
GUI Integrada, conjunto de ferramentas de console
Proficiencia com 1 a 2 dias de treino.
A usabilidade é o objetivo primário
Linguagem de definição das politicas complexa
Regras de difícil gerencia
Uma lacuna de ferramentas integradas
Investimento considerável para treinamento
Tabela comparativa das principais diferenças das estruturas.
Automação
Conforme também [suse-selinux-comparison] a automação para criação de profiles é bem mais simples e rápida veja a tabela adaptada:
AppArmor
SELinux
Open YaST Control Center
Run Server Analyzer to determine which programs to profile
Run the Profile Wizard to generate a profile template
Run the application through normal operation
Run the interactive optimizer to synthesize log events into a profile
SELinux audit2allow
Create a file at $SELINUX_SRC/domains/program/foo.te
Put the daemon domain macro call in the file
Create the file contexts file
Put the first list of file contexts in file.fc
Load the new policy with make load
Label the foo files
Start the daemon, service foo start
Examine your audit log for denial messages
Familiarize yourself with the errors the daemon is generating
Use audit2allow to start the first round of policy rules
Look to see if the foo_t domain tries to create a network socket
Continue to iterate through the basic steps to generate all the rules you need
If the domain tries to access port_t, which relates to tclass=tcp_socket or tclass=udp_socket in the AVC log message, you need to determine what port number foo_t needs to use
Iterate through the remaining AVC denials. When they are resolved with new policy, you can configure the unique port requirements for the foo_t domain
With the daemon started, determine which port foo is using
Remove the generic port_t rule, replacing it with a specific rule for a new port type based on the foo_t domain
Easy to Use—pre-defined abstractions
Easy to Modify—regular expression & wildcard support
Easy to Audit—classic Unix syntax
Custom and complex programming language
Hard-to-manage rules
Tabela comparativa do processo automatizado.
Eficiência
O Código de descrição dos perfis no AppArmor parecem ser mais eficiente, veja a tabela abaixo adaptada de [suse-selinux-compararison]:
AppArmor profile for the same program is about 4x smaller
#################################
#
# Rules for the ftpd_t domain
#
type ftp_port_t, port_type;
type ftp_data_port_t, port_type;
daemon_domain(ftpd, `, auth_chkpwd')
type etc_ftpd_t, file_type, sysadmfile;
# allow access to /home
allow ftpd_t home_root_t:dir { getattr search };v
# Create and modify /var/log/xferlog.
type xferlog_t, file_type, sysadmfile, logfile;
file_type_auto_trans(ftpd_t, var_log_t, xferlog_t, file)
# Execute /bin/ls (can comment this out for proftpd)
# also may need rules to allow tar etc...
can_exec(ftpd_t, ls_exec_t)