O Brasil é um país que sabemos ter uma baixa cultura na área de segurança. E por isto, talvez, o SeLinux tenha uma simples função aqui, ser uma das primeiras coisas que 99% dos SysAdmins que não tem muita paciência com controles mais granularizados em um sistema fazem, que é desabilitá-lo.
E o argumento central é: segurança x praticidade. E no fim, quanto mais prático, menos seguro é … como sabemos. Mas, esta discussão surgiu estes dias e eu fui procurar mais sobre o SeLinux novamente. É um produto muito legal, que ajuda demais junto com o chroot em muitos sistemas. E, este artigo super interessante apareceu e eu resolvi dividir um pouco com vocês, tendo em vista que já tem um bom tempo que não posto nada por aqui.
Então vamos lá. O chroot e o SELinux tem uma fução bem parecida. Ambos isolam um aplicativo para que ele tenha acesso somente aos recursos necessários para o seu funcionamento. O Chroot faz isto no nível de arquivo e o SELinux em recursos mais gerais e, como tudo no mundo, tem suas fraquezas e vantagens. O SELinux apesar de chato de entender é uma linguagem de políticas bem flexíveis e detalhadas que facilita o controle granularizado de segurança em um ambiente, que tem nisto também uma fraqueza. O Chroot pode suplantar isto.
Vamos a um exemplo dado no blog que eu achei super interessante. Suponhamos que exista uma falha no BIND através da qual um invasor posso ler arquivos no host ( usando o Bind como ponte ). Com o SELinux o domínio no qual o Bind é executado tem limitações de arquivos que ele possa ler.
E aqui estão as políticas padrões que o Bind roda em um sistema Linux :
- etc_runtime_t (leitura) significa acesso aos arquivos em / etc que são modificados em tempo de execução (como mtab, profile.env, /etc/env.d do gentoo)
- named_var_run_t (leitura) é o acesso a / var / run / bind e / var / run / named (e alguns outros locais relacionados)
- named_checkconf_exec_t (leitura / execução) é acesso para ler e executar / usr / sbin / named-checkconf
- named_conf_t (read) para ler os arquivos de configuração relacionados ao BIND
- dnssec_t (read) para ler os arquivos de chave DNSSEC
- locale_t (leitura) para acessar / etc / localtime, / usr / share / locale / *, / usr / share / zoneinfo / *
- etc_t (read) para ler os arquivos de configuração geral em / etc (incluindo passwd, fstab, …)
- proc_t (leitura), proc_net_t (leitura) e sysfs_t (leitura) para acessar esses pseudo-sistemas de arquivos
- udev_tbl_t (leia) para acessar /dev/.udev e / var / run / udev (mas ainda não tenho idéia do porquê disso)
- named_log_t (leitura / gravação) para os arquivos de log do BIND
- net_conf_t (read) para acessar / etc / hosts (incluindo negar / permitir), resolv.conf, …
- named_exec_t (ler / executar) os executáveis BIND
- named_zone_t (leitura) para acessar os arquivos da zona, também acesso de gravação no caso do sistema escravo
- cert_t (read) para ler as informações do certificado
- named_cache_t (leitura / gravação) para acessar seu cache
- named_tmp_t (leitura / gravação) para trabalhar com arquivos temporários
Acho que ficou bem claro aí na listagem acima muita coisa que pode acontecer né ? Veja só.
O poder de isolamento do SELinux vai até o limite dos seus rótulos. Assim, se eu permito que ele leia o diretório /etc tudo que esteja abaixo dele pode ser lido. E isto inclui arquivos como passwd, fstab, group, hosts que podem fornecer muitas informações interessantes para um atacante. Em contraposição quando o isolamento é feito via chroot somente os arquivos que estejam dentro dele é que são lidos. E nem sempre terão todas as informações que o atacante precisa para um levantamento de informações.
Mas calma, não fique tão fã do chroot, ele também tem limitações. Quando executamos o chroot sem o SELinux podemos ter a possibilidade de uma escalada de privilégios. O chroot limita o processo aos acessos regulares que são dados a um usuário, ou seja, caso o usuário consiga fazer um upload e etc de arquivos e executá-lo, ele poderá usar isto como um vetor de escalada.
Usando o SELinux podemos proibir o Bind de escrever coisas que ele também possa executar e, ainda há outro ponto. Como o domínio do Bind e o named_t ele não conseguirá executar algo fora do seu contexto. Ou seja, uma pequena gaiola bem construída mesmo.
Com este artigo ( onde ainda é citado o grsecurity ) fica claro uma coisa. Ambos os sistemas podem coexistir em um sistema e garantir maior segurança, onde o chroot limitaria ainda mais os privilégios que o SELinux dá a um processo colocando ainda um conjunto mais refinado de acesso a recursos do sistema de arquivos ( ou seja, arquivos e diretórios ).
Via Simplicity is a form of art… - Why both chroot and SELinux?