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
 
  1. Open YaST Control Center
  2. Run Server Analyzer to determine which programs to profile
  3. Run the Profile Wizard to generate a profile template
  4. Run the application through normal operation
  5. Run the interactive optimizer to synthesize log events into a profile

SELinux audit2allow

  1. Create a file at $SELINUX_SRC/domains/program/foo.te
  2. Put the daemon domain macro call in the file
  3. Create the file contexts file
  4. Put the first list of file contexts in file.fc
  5. Load the new policy with make load
  6. Label the foo files
  7. Start the daemon, service foo start
  8. Examine your audit log for denial messages
  9. Familiarize yourself with the errors the daemon is generating
  10. Use audit2allow to start the first round of policy rules
  11. Look to see if the foo_t domain tries to create a network socket
  12. Continue to iterate through the basic steps to generate all the rules you need
  13. 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
  14. 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
  15. With the daemon started, determine which port foo is using
  16. 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 SELinux
 

usr/sbin/in.ftpd {
#include <immunix-standard/base>
#include <immunix-standard/nameservice>
#include <immunix-standard/authentication>
#include <user-custom/ftpd>
/   r,
/dev/urandom    r,
/etc/fstab    r,
/etc/ftpaccess    r,
/etc/ftpconversions    r,
/etc/ftphosts   r,
/etc/ftpusers    r,
/etc/shells    r,
/usr/sbin/in.ftpd    r,
/usr/share/ssl/certs/ca-bundle.crt   r,
/usr/share/ssl/certs/ftpd-rsa.pem   r,
/usr/share/ssl/private/ftpd-rsa-key.pem   r,
/usr/share/ssl/.rnd    w,
/var/log/xferlog    w,
/var/run   wr,
/var/run/ftp.{pids,rips}-all   wr,
}

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;

can_network(ftpd_t)
can_ypbind(ftpd_t)
allow ftpd_t self:unix_dgram_socket create_socket_perms;
allow ftpd_t self:unix_stream_socket create_socket_perms;
allow ftpd_t self:process {getcap setcap};
allow ftpd_t self:fifo_file rw_file_perms;

allow ftpd_t bin_t:dir search;
can_exec(ftpd_t, bin_t)
allow ftpd_t { sysctl_t sysctl_kernel_t }:dir search;
allow ftpd_t sysctl_kernel_t:file { getattr read };
allow ftpd_t urandom_device_t:chr_file { getattr read };

ifdef(`crond.te', `
system_crond_entry(ftpd_exec_t, ftpd_t)
can_exec(ftpd_t, { sbin_t shell_exec_t })
')

allow ftpd_t ftp_data_port_t:tcp_socket name_bind;

ifdef(`ftpd_daemon', `
define(`ftpd_is_daemon', `')
') dnl end ftpd_daemon
ifdef(`ftpd_is_daemon', `
rw_dir_create_file(ftpd_t, var_lock_t)
allow ftpd_t ftp_port_t:tcp_socket name_bind;
allow ftpd_t self:unix_dgram_socket { sendto };
can_tcp_connect(userdomain, ftpd_t)
', `
ifdef(`inetd.te', `
domain_auto_trans(inetd_t, ftpd_exec_t, ftpd_t)
ifdef(`tcpd.te', `domain_auto_trans(tcpd_t, ftpd_exec_t, ftpd_t)')

# Use sockets inherited from inetd.
allow ftpd_t inetd_t:fd use;
allow ftpd_t inetd_t:tcp_socket rw_stream_socket_perms;

# Send SIGCHLD to inetd on death.
allow ftpd_t inetd_t:process sigchld;
') dnl end inetd.te
')dnl end (else) ftp_is_daemon
ifdef(`ftp_shm', `
allow ftpd_t tmpfs_t:file { read write };
allow ftpd_t { tmpfs_t initrc_t }:shm { read write unix_read unix_write associate };
')

# Use capabilities.
allow ftpd_t ftpd_t:capability { net_bind_service setuid setgid fowner fsetid chown sys_resource sys_chroot };

# Append to /var/log/wtmp.
allow ftpd_t wtmp_t:file { getattr append };

# 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)

allow { ftpd_t initrc_t } etc_ftpd_t:file r_file_perms;
allow ftpd_t { etc_t resolv_conf_t etc_runtime_t }:file { getattr read };
allow ftpd_t proc_t:file { getattr read };

')dnl end if ftp_home_dir

Tabela comparativa da eficiência em representar as regras.

Auditória

O código dos profiles também conforme [suse-selinux-comparision] se apresenta mais legível de fácil auditória:

  AppArmor SELinux
 

/usr/sbin/in.ftpd {
#include <immunix-standard/base>
#include <immunix-standard/nameservice>
#include <immunix-standard/authentication>
#include <user-custom/ftpd>
/    r,
/dev/urandom    r,
/etc/fstab    r,
/etc/ftpaccess    r,
/etc/ftpconversions    r,
/etc/ftphosts    r,
/etc/ftpusers    r,
/etc/shells    r,
/usr/sbin/in.ftpd    r,
/usr/share/ssl/certs/ca-bundle.crt    r,
/usr/share/ssl/certs/ftpd-rsa.pem    r,
/usr/share/ssl/private/ftpd-rsa-key.pem    r,
/usr/share/ssl/.rnd    w,
/var/log/xferlog    w,
/var/run    wr,
/var/run/ftp.{pids,rips}-all    wr,
}

ifdef(`ftpd_daemon', `
define(`ftpd_is_daemon', `')
') dnl end ftpd_daemon
ifdef(`ftpd_is_daemon', `
rw_dir_create_file(ftpd_t, var_lock_t)
allow ftpd_t ftp_port_t:tcp_socket name_bind;
allow ftpd_t self:unix_dgram_socket { sendto };
can_tcp_connect(userdomain, ftpd_t)
', `
ifdef(`inetd.te', `
domain_auto_trans(inetd_t, ftpd_exec_t, ftpd_t)
ifdef(`tcpd.te', `domain_auto_trans(tcpd_t, ftpd_exec_t, ftpd_t)')

# Use sockets inherited from inetd.
allow ftpd_t inetd_t:fd use;
allow ftpd_t inetd_t:tcp_socket rw_stream_socket_perms;

# Send SIGCHLD to inetd on death.
allow ftpd_t inetd_t:process sigchld;
') dnl end inetd.te
')dnl end (else) ftp_is_daemon
ifdef(`ftp_shm', `
allow ftpd_t tmpfs_t:file { read write };

Tabela Comparativa da facilidade de auditória do código

Arquitetura do SELinux vs AppArmor

Arquitetura do SELinux
Arquiteura do SELinux - Figura 1
Fonte: [IBM-Part1-SELinux] </center>
</figure>
Arquitetura do AppArmor
Arquitetura do AppArmor - Figura 2
Fonte: [Linuxformat-AppArmor]* </center>
</figure> Posteriormente estarei fazendo um estudo sobre a arquitetura interna do Linux relativa ao sistema de segurança. ## Conclusão (Resumo do Estudo com Abertura para Possíveis novos Trabalhos) Sem dúvida alguma ambas as ferramentas atingem seus objetivos, e são as melhores escolhas, a SElinux com a chancela da NSA propõem um modelo aparentemente mais robusto desenvolvido em praticamente 10 anos depesquisas, já o modelo AppArmor apresenta uma maior facilidade de uso, atendendo as necessidades do usuário menos especialista, sem deixar de lado a segurança necessária. É importante aprofundar mais na arquitetura envolvida nas ferramentas, e além disso discutir outras existentes no mercado que tem propostas diferenciadas. Ficando aberto a oportunidade de uma investigação mais profunda, arquitetura, e também mais extensa horizontalmente, outras ferramentas ## Bibliográfica - [IBM-dev-mac] https://www.ibm.com/developerworks/community/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/b_c3_aa__c3_a1_b_c3_a1_do_mac_no_linux1?lang=en (Visitado 08/02/2016) - [IBM-Part1-SELinux] - IBM - Linux Seguro: Parte 1. SELinux História de seu desenvolvimento, arquitetura e princípios operacionais http://www.ibm.com/developerworks/br/library/l-secure-linux-ru/ (Visitado em 08/02/2016) - [IBM-Anatomia-SELinux] - Anatomia do Security-Enhanced Linux (SELinux) http://www.ibm.com/developerworks/br/library/l-selinux/ (Visitado em 08/02/2016) - [WorldLibrary-AppArmor] - World Library - AppArmor http://www.worldlibrary.org/Article.aspx?ArticleId=0003721191&Title=AppArmor (Visitado 09/02/2016) - [NSA-SELinux] https://www.nsa.gov/research/selinux/ (Visitado 09/02/2016) - [NSA-SELinux-Precursors] - SELinux Precursors in NSA, Research department site https://www.nsa.gov/research/_files/selinux/papers/x/text5.shtml (Visitado 09/02/2016) - [suse-selinux-comparison] - https://www.suse.com/support/security/apparmor/features/selinux_comparison.html (Visitado 09/02/2016) - [MITRE] MITRE Corporation http://www.mitre.org/ (Visitado 09/02/2016) - [NCSA-TSRG] - NSA Trusted Systems Research Group https://www.nsa.gov/research/ia_research/index.shtml (Visitado 09/02/2016) - [Usenix-SubDomain] http://usenix.org/legacy/publications/library/proceedings/lisa2000/full_papers/cowan/cowan_html/index.html (Visitado 09/02/2016) - [Linuxformat-AppArmor] - Linux Format - AppArmor http://wiki.linuxformat.ru/wiki/LXF83:AppArmor (Visitado 09/02/2016)

Carlos Delfino

Escrito por:

Analista de Redes Windows e Linux, Analista de Desenvolvimento em diversas linguagens, incluindo para Microcontroladores, Consultor, mais de 20 anos de experiência no mercado de TICs

Google LinkedIn Digg Reddit StumbleUpon

Atualizado em