Aula #19 - Linux Security Modules - SELinux



Um sistema de computador moderno deve ser protegido, mas as necessidades variam de acordo com a sensibilidade dos dados, com o número de usuários, com a exposição a redes externas, com requisitos legais e com outros fatores. A responsabilidade por implementar boas práticas de segurança recai tanto sobre programadores de aplicativos quanto sobre os desenvolvedores do kernel do Linux. 


Os usuários também têm que seguir boas práticas como restringir privilégios dos usuários ao mínimo necessário para não expor o sistema a violações de segurança. Este capítulo descreve como o kernel do Linux aumenta a segurança por meio da utilização dos Linux Security Modules, especialmente com a implantação do SELinux.


O que é Linux Security Modules?

 Uma série de ideias foram apresentadas sobre como incorporar um módulo de segurança ao Linux. A solução foi implementar controles de acesso obrigatórios sobre os pedidos feitos ao kernel, mas fazê-lo de forma que:

    1 - Minimize alterações no kernel.
    2 - Minimize a sobrecarga no kernel.
    3 - Permita a flexibilidade de escolher entre implementações diferentes, cada uma sendo um módulo   LSM (Linux Security Module) completo e independente.

A ideia básica é interceptar as chamadas de sistema inserindo código entre entre solicitações feitas por aplicativos ao kernel (sistema); este código verifica se as permissões são válidas, e protege contra intenções maliciosas, etc. A camada de segurança faz isso antes e/ou depois que as chamadas de sistema são cumprida pelo kernel.

Durante muito tempo, o único módulo de segurança adicional disponível no Linux foi o SELinux. A primeira tentativa de integração com o Linux em 2001, não foi tranquila pois haviam dúvidas sobre o uso de apenas uma abordagem para uma melhorar a segurança.

Como resultado, a abordagem LSM foi adotada. Desta forma outros módulos de segurança também poderiam ser escritos e usados além do SELINUX. Em 2003 ele foi incorporado ao kernel do Linux.

Os módulos LSM atualmente disponíveis são:

Apenas um LSM pode ser usado de cada vez.

Vamos nos concentrar principalmente no SELinux e um pouco no AppArmor em ordem de volume de utilização.
Tabela comparando os 4: http://tomoyo.osdn.jp/wiki-e/?WhatIs#comparison



SELinux



O SELinux foi originalmente desenvolvido pela NSA (National Security Administration) dos Estados Unidos e tem sido parte integrante do RHEL por muito tempo, o que trouxe uma grande base de uso.

Operacionalmente, o SELinux é um conjunto de regras de segurança que são usadas ​​para determinar quais processos podem acessar quais arquivos, diretórios, portas e outros recursos no sistema.

Ele trabalha com três conceitos:




  •     Contextos (Context):   São labels para arquivos, processos e portos. Exemplos de contextos são usuário, papel, e tipo do SELinux.
  •     Regras (Rule): São um conjunto de regras que descrevem quais decisões sobre controle de acesso devem ser aplicadas a todo o sistema pelo SELinux.
  •     Políticas (Policy): Descreve o controle de acesso em termos de contextos, processos, arquivos, portas, usuários, etc.

Um contexto do SELinux é um nome usado por uma regra para definir como os usuários, processos, arquivos e portas interagem uns com os outros. Como a política padrão é negar qualquer acesso, as regras são usadas para descrever ações que são permitidas no sistema.
O SELinux pode rodar em um dos três modos:



    Enforcing: Todo o código do SELinux está operando e o acesso é negado de acordo com a policy. Todas as violações são auditadas e salvas em arquivos de log.



    Permissive: Habilita o código do SELinux mas apenas audita e registra em arquivos de log ações que seriam negadas no modo Enforcing.



    Disabled: Desabilita completamente o SELinux removendo as proteções para o kernel e para aplicações.


Esses modos são escolhidos (e explicados) em um arquivo (normalmente /etc/selinux/config) mas a localização varia de acordo com a distribuição (/etc/sysconfig/selinux ou tem um link para este arquivo). O arquivo é bem documentado. A ferramenta sestatus exibe o estado e a policy atuais.

Para ver e configurar o modo use getenforce e setenforce:





$ getenforce
Disabled

$ sudo setenforce Permissive

$getenforce
Permissive

setenforce pode ser utilizado para alterar entre os modos Enforcing and Permissive. No entanto não é possível habilitar ou desabilitar o SELinux desta maneira. Enquanto o setenforce permite alterar entre os modos Permissive e Enforcing, ele não permite desabilitar o SELinux completamente. Existem ao menos duas formas de desabilitar o SELinux:
    Arquivo de configuração: edite o arquivo de configuração do SELinux (normalmente /etc/selinux/config) e defina SELINUX=disabled. Esta é a forma padrão e deve ser usada para desligar o SELinux. de forma persistente.
    Parâmetro do Kernel: Adicionar selinux=0 na linha de comando do Kernel ao reiniciar.

Desabilitar o SELinux em sistemas em que o SELinux será usado em produção não é recomendado. Use o modo Permissive ao invés de desabilitar o SELinux, para evitar o processo de relabel de todo o sistema de arquivos que pode ser bem demorado.

 O arquivo de configuração, normalmente /etc/sysconfig/selinux também define a política (policy) do SELinux. Várias políticas são permitidas, mas somente uma pode estar ativa de cada vez. Alterar a política pode exigir reiniciar do sistema e um processo de re-labeling demorado que depende da quantidade de arquivos em disco. Os arquivos específicos de cada política são instalados em /etc/selinux/[TIPODESELINUX].



Policy

As políticas (policy) mais comuns são:
Targeted: A política padrão em que o SELinux é mais restrito com processos específicos. Processos dos usuários e processos init não são o principal alvo. O SELinux impõe restrições de memória para todos os processos, o que reduz a vulnerabilidade a ataques de buffer overflow.

Minimum: Uma modificação da política Targetd onde apenas os processos selecionadas estão protegidos.
    
MLS: Uma política Multi-Level Security (ou política de vários níveis de segurança) é muito mais restritiva; todos os processos são colocados em domínios de segurança de pente fino e com políticas específicas.
   

Como mencionado anteriormente, os contextos são rótulos ou etiquetas aplicadas a arquivos, diretórios, portas e processos. Esses rótulos são usados ​​para descrever as regras de acesso. Há quatro contextos do SELinux:
  •     User (Usuário)
  •     Role (Função)
  •     Type (Tipo)
  •     Level (Nível)



No entanto, vamos nos concentrar no Type, que é o contexto mais comumente utilizado. A convenção de nomenclatura determina que nomes de contexto do tipo Type devem terminar com _t como em kernel_t.


Muitas ferramentas de linha de comando como o ls e o ps, foram estendidos para suportar recursos do SELinux, e documentação foi adicionada nas man pages desses comandos explicando os detalhes. É comum que o parâmetro Z seja passado para ferramentas comuns de linha de comando como em:


$ ps axZ
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t:s0 1 ? Ss 0:04 /usr/lib/systemd/systemd --switched-root ...
system_u:system_r:kernel_t:s0 2 ? S 0:00 [kthreadd]
...
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2305 ? D 0:00 sshd: [email protected]/0
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2306 pts/0 Ss 0:00 -bash
...
system_u:system_r:httpd_t:s0 7490 ? Ss 0:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0 7491 ? S 0:00 /usr/sbin/httpd -DFOREGROUND
...


$ ls -Z /home/ /tmp/
/home/:
drwx------. peter peter unconfined_u:object_r:user_home_dir_t:s0 peter
/tmp/:
-rwx------. root root system_u:object_r:initrc_tmp_t:s0 ks-script-c4ENhg
drwx------. root root system_u:object_r:tmp_t:s0 systemd-private-0ofSvO
-rw-------. root root system_u:object_r:initrc_tmp_t:s0 yum.log


Outras ferramentas que foram estendidas para suportar o SELinux incluem cp, mv, e mkdir.

Se você desabilitou o SELinux, nenhuma informação sobre o SELinux é exibida pelas ferramentas apresentadas.

Arquivos recém-criados herdam o contexto do diretório onde foram criados, mas ao mover ou copiar arquivos, o contexto do diretório de origem é mantido, o que pode causar problemas.

Continuando o exemplo anterior, vemos que o contexto do arquivo arquivo_tmp não foi alterado ao mover da pasta /tmp para /home/peter:

$ cd /tmp/ $ touch arquivo_tmp $ ls -Z arquivo_tmp

-rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 arquivo_tmp


$ cd
$ touch arquivo_home
$ ls -Z arquivo_home

-rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 arquivo_home



$ mv /tmp/arquivo_tmp . $ ls -Z

-rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 arquivo_home

-rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 arquivo_tmp



O exemplo clássico me que mover arquivos cria um problema com o SELinux é mover arquivos para o diretório DocumentRoot do servidor httpd.  Em sistemas que usam o SELinux o servidor web só pode acessar arquivos com o label correto. Criar um arquivo no /tmp, e depois mover para o diretório DocumentRoot vai tornar o arquivo inacessível para o servidor httpd até que o contexto SELinux do arquivo seja ajustado.




RESTORECON


O restorecon reseta o contexto de arquivos, baseado na configuração do diretório em que o arquivo se encontra no momento. No exemplo a seguir, o restorecon reseta o label recursivamente para todos os arquivos no diretório home:
$ ls -Z
-rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile -rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 tmpfile



$ restorecon -Rv /home/peter
restorecon reset /home/peter/tmpfile context \ unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:user_home_t:s0






 
$ ls -Z -rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile -rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 tmpfile


Observe que o contexto do arquivo tmpfile foi resetado para o contexto da pasta home. O tipo foi alterado de user_tmp_t para user_home_t.




semanage fcontext



Uma outra questão é como configurar o contexto padrão para um novo diretório.  semanage fcontext (fornecido pelo pacote policycoreutils-python) pode alterar e exibir o contexto padrão de arquivos e diretórios. Lembre-se que o semanage fcontext apenas altera os padrões, e não aplica o novo padrão aos objetos existentes. Para aplicar a nova configuração aos objetos existentes use o restorecon depois de alterar o padrão.  Por exemplo:
[[email protected] /]# mkdir /virtualHosts

[[email protected] /]# ls -Z

...

drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 virtualHosts



[[email protected] /]# semanage fcontext -a -t httpd_sys_content_t /virtualHosts

[[email protected] /]# ls -Z

...

drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 virtualHosts



[[email protected] /]# restorecon -RFv /virtualHosts

restorecon reset /virtualHosts context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0

[[email protected] /]# ls -Z

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 virtualHosts


A troca de contexto de default_t para httpd_sys_content_t é de fato aplicada apenas após chamar o restorecon.




booleans

O comportamento de uma policy do SELinux pode ser ajustado sem precisar de um reboot. Isso é feito com os booleans do SELinux que são parâmetros que podem ser ligados e desligados.

Para ver todos os booleans com uma pequena descrição:

$ sudo semanage boolean -l
SELinux boolean             State   Default   Description
ftp_home_dir                  (off , off)      Allow ftp to home dir
smartmon_3ware                (off , off)      Allow smartmon to 3ware
mpd_enable_homedirs           (off , off)      Allow mpd to enable homedirs
xdm_sysadm_login              (off , off)      Allow xdm to sysadm login
xen_use_nfs                   (off , off)      Allow xen to use nfs
mozilla_read_content          (off , off)      Allow mozilla to read content
...
nfs_export_all_rw              (on , on)       Allow nfs to export all rw
pcp_bind_all_unreserved_ports (off , off)      Allow pcp to bind all unreserved ports
postgresql_selinux_transmit_client_label (off , off) Allow postgresql to selinux transmit client label
collectd_tcp_network_connect  (off , off)      Allow collectd to tcp network connect
cobbler_use_cifs              (off , off)      Allow cobbler to use cifs
mcelog_server                 (off , off)      Allow mcelog to server
httpd_setrlimit               (off , off)      Allow httpd to setrlimit
squid_connect_any              (on , on)       Allow squid to connect any
ssh_sysadm_login              (off , off)      Allow ssh to sysadm login
domain_fd_use                  (on , on)       Allow domain to fd use
virt_use_samba                (off , off)      Allow virt to use samba
cluster_use_execmem           (off , off)      Allow cluster to use execmem
nfs_export_all_ro              (on , on)       Allow nfs to export all ro
cron_can_relabel              (off , off)      Allow cron to can relabel
sftpd_anon_write              (off , off)      Allow sftpd to anon write




Uma alternativa para a exibir informação simples sobre os booleans do SELinux é chamar o getsebool -a que imprime apenas o nome e o estado atual.

setsebool é usado para alterar o estado dos booleans. O comportamento padrão é aplicar as alterações imediatamente, mas que não são persistentes após reiniciar o sistema. No entanto, o parâmetro -P pode ser fornecido a fim de fazer as mudanças persistentes a reinicialização.

Um exemplo de alteração não persistente usando o setsebool:


$ getsebool ssh_chroot_rw_homedirs ssh_chroot_rw_homedirs --> off

$ sudo setsebool ssh_chroot_rw_homedirs on $ getsebool ssh_chroot_rw_homedirs ssh_chroot_rw_homedirs --> on


$ sudo reboot

...

$ getsebool ssh_chroot_rw_homedirs ssh_chroot_rw_homedirs --> off





Um exemplo de alteração persistente usando o setsebool  -P:


$ getsebool ssh_chroot_rw_homedirs ssh_chroot_rw_homedirs --> off



$ sudo setsebool -P ssh_chroot_rw_homedirs on $ getsebool ssh_chroot_rw_homedirs ssh_chroot_rw_homedirs --> on
$ sudo reboot

...


$ getsebool ssh_chroot_rw_homedirs

ssh_chroot_rw_homedirs --> on







Ferramentas para solução de problemas




O SELinux vem com um conjunto de ferramentas para detectar problemas durante a execução, salvar estes problemas em arquivos de log, e propor soluções para impedir que os mesmo problemas ocorram novamente. Esses utilitários são fornecidos pelo pacote setroubleshoot-server. Um exemplo do uso:


[[email protected] ~]# echo 'Arquivo criado no /root' > rootfile


[[email protected] ~]# mv rootfile /var/www/html/

[[email protected] ~]# wget -O - localhost/rootfile

--2014-11-21 13:42:04--  http://localhost/rootfile

Resolving localhost (localhost)... ::1, 127.0.0.1

Connecting to localhost (localhost)|::1|:80... connected.

HTTP request sent, awaiting response... 403 Forbidden

2014-11-21 13:42:04 ERROR 403: Forbidden.



[[email protected] ~]# tail /var/log/messages

Nov 21 13:42:04 rhel7 setroubleshoot: Plugin Exception restorecon

Nov 21 13:42:04 rhel7 setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file .

For complete SELinux messages. run sealert -l d51d34f9-91d5-4219-ad1e-5531e61a2dc3

Nov 21 13:42:04 rhel7 python: SELinux is preventing /usr/sbin/httpd from getattr access on the file .



*****  Plugin catchall (100. confidence) suggests  **************************



If you believe that httpd should be allowed getattr access on the  file by default.

Then you should report this as a bug.

You can generate a local policy module to allow this access.

Do

allow this access for now by executing

# grep httpd /var/log/audit/audit.log | audit2allow -M mypol

# semodule -i mypol.pp





[[email protected] ~]#  sealert -l d51d34f9-91d5-4219-ad1e-5531e61a2dc3

SELinux is preventing /usr/sbin/httpd from getattr access on the file .



*****  Plugin catchall (100. confidence) suggests  **************************



If you believe that httpd should be allowed getattr access on the  file by default.

Then you should report this as a bug.

You can generate a local policy module to allow this access.

Do

allow this access for now by executing:

# grep httpd /var/log/audit/audit.log | audit2allow -M mypol

# semodule -i mypol.pp



Additional Information:
Source Context system_u:system_r:httpd_t:s0
Target Context unconfined_u:object_r:admin_home_t:s0
Target Objects [ file ]
Source httpd
Source Path /usr/sbin/httpd
Port
Host rhel7
Source RPM Packages httpd-2.4.6-18.el7_0.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.12.1-153.el7_0.11.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name rhel7
Platform Linux rhel7 3.10.0-123.9.3.el7.x86_64 #1 SMP Thu
Oct 30 00:16:40 EDT 2014 x86_64 x86_64
Alert Count 2
First Seen 2014-11-21 12:34:13 CET
Last Seen 2014-11-21 13:42:04 CET
Local ID d51d34f9-91d5-4219-ad1e-5531e61a2dc3


Raw Audit Messages
type=AVC msg=audit(1416573724.395:1598): avc: denied { getattr } for pid=20180 comm="httpd"
path="/var/www/html/rootfile" dev="dm-0" ino=70624441 scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file


type=SYSCALL msg=audit(1416573724.395:1598): arch=x86_64 syscall=lstat success=no exit=EACCES
a0=7f2896ed0578 a1=7fffcc64fb30 a2=7fffcc64fb30 a3=0 items=0 ppid=20178 pid=20180
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)


Hash: httpd,httpd_t,admin_home_t,file,getattr


Observe que no RHEL 7 a sugestão é rodar:

$ grep httpd /var/log/audit/audit.log |  audit2allow -M mypol

audit2allow é uma ferramenta que gera policy rules para o SELinux a partir de logs de operações negadas. Uma ferramenta similar é o audit2why, que traduz mensagens de auditoria do SELinux em uma descrição do motivo por traz do acesso negado.


O próximo exemplo mostra como resolver o problema usando a ferramenta  restorecon que foi descrita anteriormente.  Sinta-se a vontade para tentar os dois métodos para resolver o problema com o SELinux.



[[email protected] ~]# restorecon -Rv /var/www/html/
restorecon reset rootfile context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:httpd_sys_content_t:s0


[[email protected] ~]# wget -q -O - localhost/rootfile
Arquivo criado no /root




Há recursos online disponíveis gratuitamente para o SELinux incluindo tópicos avançados:

Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide ( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide ) No momento da tradução deste curso, a Red Had ainda não havia disponibilizado a versão traduzida para português do Brasil. Para verificar se a tradução já está disponível, verifique o link: https://access.redhat.com/documentation/pt-BR/Red_Hat_Enterprise_Linux/7/


Red Hat Enterprise Linux 6 Security-Enhanced Linux ( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/ ) No momento da tradução deste curso, a Red Had ainda não havia disponibilizado a versão traduzida para português do Brasil. Para verificar se a tradução já está disponível, verifique o link: https://access.redhat.com/documentation/pt-BR/Red_Hat_Enterprise_Linux/6/


Tabelas comparando os diferentes Security Modules:

AppArmor vs SELinux
https://www.suse.com/support/security/apparmor/features/selinux_comparison.html

Tomoyo1.8 vs Tomoyo2.5 vs AKARI
http://akari.osdn.jp/comparison.html

SELinux vs AppArmor vs Grsecurity
http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html







AppArmor

O AppArmor é um módulo LSM, e logo uma alternativa ao SELinux. Suporte foi incorporado no kernel do Linux em 2006. Ela tem sido usado pelo SUSE, Ubuntu e outras distribuições.


O AppArmor:

  •     Fornece Mandatory Access Control (MAC).
  •     Permite que os administradores associem um perfil de segurança(capaz de restringicapacidades) a um programa.
  •     É considerado mais fácil (por alguns, mas não todos) de usar do que o SELinux.
  •     É considerado independente do sistema de arquivos (sem a necessidade de usar labels para arquivos e pastas).

O AppArmor complementa o modelo de privilégios tradicional do UNIX chamado Discretionary Access Control (DAC) através do Mandatory Access Control (MAC).

Além de especificar manualmente perfis, o AppArmor inclui um modo de aprendizagem, em que as violações do perfil são registrados, mas não impedidas. Este registro pode então ser transformado em um perfil, com base no comportamento típico do programa.

Mais vistos no mês:

As melhores distribuições Linux para 2017

TuxMath - Tux, do Comando da Matemática. Ensino e diversão a crianças.

Teste de Performance de Rede com Iperf

DHCP - Guia Completo

Aula #14 - Os sistemas de arquivos ext2/ext3/ext4

OPNsense - Firewall Open Source

Ophcrack: Descubra todas as senhas do Windows

SSD no linux

Administração de sistema e Deploys: Ansible, Chef, Fabric, Puppet ou Salt?

Brískola - aprenda a jogar !!