Tipos de Políticas de Segurança SELinux

- Política Strict:
Um sistema que usa a política de segurança strict é aquele onde tudo é negado por padrão, é nescessário habilitar regras na política de segurança para cada tarefa que cada aplicação ou processo irá realizar. O SELinux foi concebido originalmente para atender à política strict, pois as políticas são somente de permissão e não de bloqueio.

Para um sistema generalista como é o Linux, atender ao uso de uma política strict é uma grande e complexa tarefa. As primeiras experiências de uso da política strict no sistema operacional Linux foram na distribuição Fedora Core versão 2, onde a política era desabilitada por padrão. Esse novo recurso causou curiosidade em muitos administradores de sistemas, que por desejo de tornar o seu sistema mais seguro, habilitaram o uso da política strict durante a instalação. Como a política strict ainda não era madura o suficiente para seu uso em sistemas comerciais (o Linux Fedora Core é uma distribuição usada pela Red Hat para testar novos recursos e amadurecimento de versões de aplicações para depois então serem aplicados no Red Hat Linux) e não atendia todos os programas disponíveis na distribuição Fedora, acabaram ocorrendo muitos problemas em seu uso, e esse deve ter sido o fato que motivou a "má fama" que o SELinux ganhou de ser um sistema muito complexo, que apenas trazia mais problemas para serem contornados pelos administradores de sistemas, tanto que a principal pergunta em fóruns de internet sobre segurança e SELinux da época era: "Como desabilito o SELinux?" [1]

Desde então muita coisa mudou no SELinux até os dias atuais, pois hoje a política strict se mostra utilizável em sistemas Linux para muitos casos. Os incidentes ocorridos nas distribuições Fedora 2 levaram a criação de uma nova política de segurança SELinux, a targeted, e a criação de um novo domínio chamado unconfined_t. [2]


- Política Targeted:
Através da política targeted, cada sujeito e objeto roda em um domínio chamado unconfined_t exceto alguns serviços alvos que possuem políticas pré-definidas. Objetos que estão no domínio unconfined_t não possuem restrições e usam a segurança Linux padrão (DAC), ou seja, rodam como se não existisse o SELinux para realizar os controles de segurança. Os serviços que fazem parte da política targeted rodam em seus próprios domínios e são restritos à política para cada operação que realizam no sistema, dessa forma se esses serviços forem comprometidos ou de alguma maneira explorados por suas vulnerabilidades, os danos são limitados e até mesmo podem ser controlados.

Como exemplo, o servidor web apache é protegido pela política targeted, e não poderá comprometer os outros serviços do sistema, como servidor de nomes, servidor ssh, arquivos privados de usuários, etc, conforme a política pré-definida. No formato padrão DAC, isso não acontece, um bom exemplo disso é a vulnerabilidade no aplicativo gerenciador de conteúdo web chamado Mambo, que na versão 4.0.14 é vulnerável ao ataque descrito na CVE-2005-3738 [3]. O SELinux é capaz de limitar esse ataque a ponto de torná-lo inútil. [4]

A política targeted é a padrão na maioria das distribuições Linux que usam SELinux, como Fedora 3 ou superior e Red Hat 4 ou superior.


OBS: Na versão 8 do Fedora Core Linux lançada em novembro de 2007, que é a distribuição Linux onde a maioria do desenvolvimento do SELinux é realizada e são propostos e implementados novos recursos e várias mudanças, a política strict deixou de existir como uma política totalmente isolada da política targeted, foi criada uma política híbrida onde tanto a política targeted quanto a strict é utilizada. No Fedora 8 é possível usar a política strict por usuário, adicionando o usuário em um domínio strict (domínio guest ou xguest, por exemplo), e esse usuário estará com limitações de acessos como era antigamente usando-se a política strict. Por padrão, os usuários serão criados ainda no domínio unconfined_t. Para remover totalmente a habilidade de processos executarem no domínio unconfined_t, pode-se remover o módulo unconfined com o comando "semodule -r unconfined". [5]

No próximo post, comentarei sobre políticas MLS e MCS no SELinux.

Referências:
[1]: http://selinux-symposium.org/2005/presentations/session4/4-1-walsh.pdf
[2]: http://danwalsh.livejournal.com/9031.html
[3]: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3738
[4]: http://www.linuxjournal.com/article/9176
[5]: http://fedoraproject.org/wiki/Interviews/SELinux