O modelo convencional de segurança do Linux, restrito basicamente às permissões de acesso no formato user-group-others, é uma característica que remonta ao surgimento dos sistemas Unix. Embora essas permissões sejam relativamente simples de entender, elas não são suficientes para bloquear determinados tipos de ataques, que só poderiam ser evitados com um sistema de segurança mais sofisticado.
Visando exatamente preencher as lacunas no sistema de segurança do Linux, a Agência Nacional de Segurança dos Estados Unidos – NSA, empenhou-se para implementar algumas modificações no kernel que acrescentam uma camada de segurança mais especializada. Esse conjunto de modificações ficou conhecido como Security-Enhanced Linux (Segurança aprimorada do Linux), ou simplesmente SELinux.
Anteriormente restrito a pesquisas acadêmicas e sistemas críticos, nos últimos anos o SELinux vem se estabelecendo como a mais importante alternativa para melhorar a segurança das principais distribuições Linux corporativas. Este artigo irá apresentar os conceitos envolvidos no SELinux e exemplificar algumas situações nas quais ele poderá trazer enormes benefícios para a segurança do sistema.
DAC versus MAC
Mas antes de esbanjar qualquer explicação específica sobre o SELinux, é essencial esclarecer o conceito mais abrangente no qual se insere: os mecanismos de controle de acesso (ACM). Entre um número razoável de mecanismos existentes para diferentes tipos de sistemas, destacam-se os dois mais comuns que estarão envolvidos na discussão, o DAC (Controle de acesso discricionário) e o MAC (Controle de acesso obrigatório).
O DAC, apesar de ser uma sigla pouco conhecida, é o mecanismo de controle de acesso mais popular, padrão em todos os principais sistemas operacionais para servidores. Ele é o típico controle de acesso por permissões que conhecemos nos sistemas Unix e Windows, baseado na noção de que usuários individuais são os donos (owner) dos objetos e, portanto, têm controle (discrição) total de quem tem as permissões para acessá-los.
Por exemplo, se um usuário é o dono de um arquivo, ele poderá conceder a outro usuário, ou grupo de usuários, a permissão para acessá-lo em qualquer modo de operação (leitura, gravação e execução). Posteriormente, ele poderá revogar essa permissão a qualquer momento.
Enquanto o ponto-chave do DAC é o fato de que os usuários são considerados donos do objeto e responsáveis pelas suas permissões de acesso, o mecanismo MAC prevê que usuários individuais não têm escolha em relação às permissões de acesso que eles possuem ou que objetos podem acessar. No MAC, apenas os administradores do sistema têm controle sobre as políticas de segurança, que são definidas em nível organizacional.
Ao contrário do DAC, os usuários não podem modificar as políticas definidas no MAC, seja acidental ou intencionalmente. Isso garante que o administrador defina uma política de segurança centralizada que, em princípio, é aplicada a todos os usuários do sistema. É exatamente o MAC o mecanismo de controle de acesso no qual se baseia o SELinux.
Visão geral do SELinux
O SELinux oferece então um sistema de controle de acesso obrigatório (MAC), flexível e incorporado ao kernel do Linux através de um conjunto de módulos específicos, chamados de Linux Security Modules, cujo desenvolvimento teve como principal objetivo viabilizar o SELinux no kernel 2.6.
Importante deixar claro que o SELinux não substitui o tradicional mecanismo de controle de acesso DAC do Linux. Ele simplesmente complementa-o, verificando se uma determinada operação é permitida após as permissões padrões do usuário já terem sido checadas. O propósito de um kernel com SELinux é proteger todo o sistema contra aplicativos maléficos ou defeituosos que possam comprometê-lo ou danificá-lo, em situações de ataque onde o sistema tradicional de permissões é incapaz de impedir.
Por exemplo, um processo rodando com o usuário root, de acordo com as premissas do mecanismo DAC, é um processo que tem permissão para ler e escrever em qualquer arquivo do sistema. Um atacante poderá conseguir acesso aos arquivos do sistema explorando uma vulnerabilidade no servidor de e-mail rodando como root, como, por exemplo, o sendmail. Isso irá permitir, em tese, que o atacante modifique através do servidor de e-mail vulnerável o arquivo de senhas /etc/passwd, mesmo que esse servidor de e-mail, em seu funcionamento normal, nunca precise escrever nesse arquivo.
Precisamente nesse ponto o SELinux irá adicionar um controle de acesso mais refinado. O servidor de e-mail continuará sendo executado como root, porém, o sistema irá evitar, dentre outras coisas, que ele modifique o arquivo de senhas.
SELinux na prática
Tomando como exemplo o Red Hat Enterprise Linux 4 – primeira distribuição comercial a adotar o SELinux – a configuração padrão já define políticas de segurança específicas para proteger determinados servidores (daemons), como o Apache, dhcpd, portmap, named, dentre outros. Esse modelo ajudou a amadurecer o SELinux nessa distribuição, que foi melhor incorporado no Red Hat Enterprise Linux 5.
Essa mesma distribuição, que se dedica bastante no desenvolvimento e integração do SELinux, oferece algumas ferramentas para facilitar o gerenciamento das políticas e a análise de problemas decorrentes do SELinux, além de estar constantemente oferecendo novas políticas de segurança para proteger outras aplicações.
Apesar de ser razoavelmente complexo, construir políticas de segurança personalizadas é absolutamente possível para o administrador de sistemas. Contudo, utilizar as políticas padrões de uma distribuição geralmente é a melhor alternativa. A complexidade do SELinux, combinada principalmente a alguns problemas de compatibilidade, são fatores que dificultam sua adoção nos servidores. Cabe à distribuição facilitar essa tarefa e predefinir regras que atendam às principais necessidades dos diferentes tipos de sistemas.
Considerações finais
Graças aos esforços dos desenvolvedores, o SELinux conseguiu chamar a atenção das principais distribuições Linux corporativas, além de grandes empresas que atualmente apóiam seu desenvolvimento. Hoje ele se projeta como uma alternativa pragmática para ambientes computacionais de qualquer porte, onde a preocupação com a segurança e confidencialidade das informações é uma questão de sobrevivência.
Para o futuro, o desenvolvimento do SELinux dá pistas de que ruma para a consolidação desse modelo de controle de acesso nos servidores, abrangendo uma variedade maior de aplicações e alcançando compatibilidade com os mais diversos ambientes. Agora um dos objetivos é reforçar as ferramentas para gerenciamento das políticas de segurança, o que conseqüentemente resultaria em facilidade de gerenciamento e desenvolvimento de novas políticas.
Saiba mais
Para mais detalhes técnicos a respeito do SELinux, vale a pena consultar a documentação disponível neste link
E uma lista detalhada de todos os itens sob pesquisa do SELinux pode ser encontrada neste link.
Referências
Don Marti (24-02-2008). A seatbelt for server software: SELinux blocks real-world exploits. LinuxWorld.com. Acessado em 05-03-2008.
Wikipédia (07-03-2008). Discretionary access control. Acessado em 10-03-2008.
Bastante esclarecedor este artigo. Gostaria de acrescentar dizendo que podemos utilizar todas essas características do Red Hat Enterprise Linux 4 e 5 através da distribuição CentOS, na minha opinião, a melhor disto para servidores.
Ótimo artigo!
Gostaria apenas de fazer uma observação: no quinto parágrafo, onde consta “discreção”, o correto é “discricionariedade”. Vide:
http://pt.wiktionary.org/wiki/discricionariedade
http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portugues…
Olá Mário,
Realmente havia um erro, mas acredito que nesse contexto, ao invés de discricionariedade, o melhor seria discrição, como “capacidade de discernir”, já que faz referência a expressão “ter controle”.
Já fiz a correção e agradeço a observação.
Um abraço.
Parabéns pelo post!
Fiz alguns posts sobre selinux também, caso queira dar uma olhada:
http://jczucco.blogspot.com/search/label/selinux
Uma ótima introdução, valeu a pena!
Lembrando que o Ubuntu também está cogitando adicionar o SELinux na sua próxima versão. Isso é um bom sinal…