Linux Seguro: Parte 1. SELinux – história de seu desenvolvimento, arquitetura e princípios operacionais

Saiba mais sobre os marcos básicos do desenvolvimento, da arquitetura e dos princípios operacionais do Security-Enhanced Linux, o remix eficiente do Linux que fornece controle de acesso obrigatório. Este artigo foi especialmente selecionado para a tradução pela developerWorks Rússia como um exemplo de developerWorks nas ofertas em todo o mundo.

Evgeny Ivashko, Specialist, Author

Evgeny Ivashko, membro do Instituto da Academia Russa de Ciências, Instituto de Pesquisa Matemática Aplicada e do Centro Careliano de Pesquisas da Academia Russa de Ciências



16/Mai/2014

História do SELinux

O projeto do desenvolvimento do Security-Enhanced Linux® (SELinux), um sistema que oferece controle de acesso obrigatório, foi iniciado dentro da Agência de Segurança Nacional dos EUA (NSA). As empresas Secure Computing Corporation (SCC) e MITRE participaram diretamente do desenvolvimento, junto com vários laboratórios de pesquisas. Foi lançado como um produto de software de acesso geral (com o código fonte distribuído sob uma licença GPL) em dezembro de 2000. Um press release especial foi emitido pela NSA para marcar a ocasião (consulte Recursos). Naquela época, já tinham sido empregados 10 anos em desenvolvimento, análise e teste da arquitetura básica do SELinux, como parte de vários projetos híbridos, militares e de pesquisa (consulte Project extravaganza: DTMach, DTOS, Fluke, Flusk, Flask).


Project extravaganza: DTMach, DTOS, Fluke, Flusk, Flask

De 1992 a 1993, pesquisadores da NSA e da SCC estavam trabalhando na criação do sistema operacional Distributed Trusted Mach (DTMach), que combinou os resultados obtidos com os projetos TMach e LOCK. O DTMach combinou o cumprimento de tipos genéricos, um mecanismo de controle de acesso flexível e um microkernel do Mach. Em seguida, o projeto DTMach foi desenvolvido como parte do projeto Distributed Trusted Operating System (DTOS). Após a conclusão do projeto DTOS, os esforços da NSA, SCC e da Universidade de Utah foram combinados para integrar a arquitetura do sistema de segurança DTOS ao sistema operacional de pesquisa Fluke. O novo projeto foi denominado Flux. Paralelamente, a arquitetura original do sistema de segurança foi aprimorada, permitindo o fornecimento de um suporte melhor às políticas de segurança dinâmica. A nova arquitetura aprimorada foi denominada Flask. Na etapa seguinte, a NSA implementou essa arquitetura de sistema de segurança no sistema operacional Linux. Isso foi colocado à disposição do público com o nome Security-Enhanced Linux (consulte Recursos).

O novo sistema de controle de acesso se baseou no processo de verificação dos rótulos de segurança dos objetos e sujeitos do sistema operacional e incluiu várias das tecnologias de controle de acesso mais recentes. Uma dessas tecnologias foi o cumprimento de tipos. Ele foi testado inicialmente em um sistema de nível "A1" especialmente projetado e confiável, conhecido como LOCK (consulte LOCK) e, em seguida, desenvolvido no subsistema de segurança do sistema operacional de pesquisa Flask. O uso de cumprimento de tipos suporta especificamente a implementação, usando o controle de acesso baseado em função do SELinux e a segurança de vários níveis ou várias categorias.


Cumprimento de tipos

O cumprimento de tipos é uma tecnologia de controle de acesso em que os direitos que permitem que o sujeito (usuário, processo de software e fluxo) acesse o objeto (arquivo, porta de E/S e outros) são concedidos de acordo com o contexto de segurança ou domínio atual.

No SELinux, o contexto de segurança é armazenado nos atributos do sistema de arquivos estendido e gerenciado usando o Linux Security Module (LSM). O cumprimento de tipos é necessário para implementar o controle de acesso obrigatório. Ele complementa o controle de acesso baseado em função (RBAC) e é uma das primeiras etapas de Multi-Level Security (MLS) e de Multi-Category Security (MCS).


LOCK

O objetivo do projeto LOCK (Logical Co-processing Kernel), no qual a SCC trabalhou, era desenvolver um sistema de computador confiável, que fornecesse segurança de vários níveis. Para isso, o sistema tinha que preencher os requisitos do "A1", de acordo com os Critérios de Avaliação de Sistemas de Computação Confiável (também conhecidos como "Orange Book").

O projeto foi concluído com êxito, resultando em diversos sistemas que foram configurados em centros de comando militares. O cumprimento de tipos foi o principal recurso arquitetônico da tecnologia LOCK, garantindo a implementação efetiva do mecanismo de controle de acesso.

Tecnologias LOCK básicas relacionadas à segurança e ao controle de acesso (incluindo o cumprimento de tipos) estão sendo desenvolvidas nos seguintes sistemas:

  • Linha de produtos Sidewinder Internet Firewall
  • SELinux

Veja informações mais detalhadas sobre o projeto LOCK em Recursos.

Quando foi lançado, o SELinux foi distribuído como uma atualização dos kernels 2.2 e 2.4. Entretanto, com a discussão da possibilidade de incluir o SELinux no kernel oficial, Linus Torvalds solicitou a modificação do projeto para que o subsistema de segurança Linux pudesse ser implementado como um módulo, facilitando a sua manutenção subsequente ou aprimoramento. Consequentemente, os desenvolvedores criaram o subsistema Linux Security Modules, fornecendo as funções kernel com uma interface para o subsistema de segurança. Essa solução permite que usuários e desenvolvedores de distribuições Linux escolham entre vários sistemas de controle de acesso: AppArmor, TOMOYO Linux, SMACK e SELinux.


Linux Security Modules

O Linux Security Modules (LSM) é um subsistema projetado para integrar ao kernel vários modelos de segurança implementados como módulos. Em 2001, representantes da NSA no Linux Kernel Summit sugeriram a inclusão do sistema de controle de acesso obrigatório Security-Enhanced Linux no kernel Linux versão 2.5. Entretanto, Linus Torvalds rejeitou essa sugestão, já que o SELinux não era o único sistema para aumentar a segurança do Linux em desenvolvimento. Além disso, nem todos os desenvolvedores concordaram que o SELinux era a melhor solução. Em vez de incluir o SELinux diretamente no kernel, criou-se o sistema Linux Security Modules, permitindo o uso de subsistemas de segurança como módulos. Dessa forma, a conexão de novos módulos se tornou relativamente simples.

O trabalho de desenvolvimento do subsistema LSM continuou por aproximadamente três anos e foi incluído no kernel Linux a partir da versão 2.6. Os módulos de segurança suportados atualmente de forma oficial são o SELinux, Apparmor, Smack e TOMOYO Linux.

Uma descrição detalhada da arquitetura do LSM é fornecida no artigo "Linux Security Modules: General Security Support for the Linux Kernel" (consulte Recursos), apresentado na conferência USENIX Security em 2002.

O SELinux está relacionado aos sistemas de controle de acesso baseados no controle de rótulos. Isso significa que cada objeto ou sujeito do sistema operacional protegido pelo SELinux precisa ter o seu próprio rótulo especial, chamado de contexto de segurança. Inicialmente, esses rótulos foram armazenados como números nos campos não utilizados nos nós do sistema de arquivos ext2. Cada rótulo numérico foi correlacionado no SELinux a um rótulo de contexto de segurança baseado em texto e legível para pessoas. Essa abordagem não era escalável e se baseava nos recursos do sistema de arquivos ext2 específico, o que foi considerado como uma desvantagem óbvia da solução como um todo.

Durante a fase seguinte do desenvolvimento, o SELinux foi implementado como um módulo que podia ser carregado no kernel Linux versão 2.4. O módulo operava com rótulos armazenados em um arquivo separado, ou seja, essa implementação do SELinux não tinha restrições em relação ao sistema de arquivos. Entretanto, a remoção de uma falha arquitetônica provocou o aparecimento de outra falha. O acesso frequente ao arquivo que contém os rótulos do contexto de segurança causava uma grande redução da produtividade.

O problema finalmente foi resolvido com o release do kernel Linux versão 2.6, com o suporte total do Linux Security Modules e dos atributos estendidos no sistema de arquivos ext3. Para poder armazenar os rótulos do contexto de segurança dos objetos e sujeitos do sistema, o SELinux passou a usar atributos estendidos. Infelizmente, essa inovação também provocou restrições relacionadas ao uso do sistema de arquivos. O SELinux só podia ser usado em sistemas de arquivos que suportavam atributos estendidos. Contudo, esse problema começou a diminuir ao longo do tempo. Atualmente, praticamente todos os sistemas de arquivos utilizados com frequência têm suporte total a atributos estendidos e podem ser usados com o SELinux.

Algum tempo depois, o SELinux foi integrado ao kernel Linux e começou a ser distribuído para teste pela primeira vez como um subsistema do kernel 2.6.0-test3, lançado em 8 de agosto de 2003. Como parte disso, foi lançado um patch para os kernels 2.2 e 2.4, referente ao sistema de controle de acesso obrigatório, ao passo que a introdução do suporte para o Linux Security Modules no kernel 2.4 levou ao release de uma versão SELinux para o LSM.

O SELinux se tornou muito rapidamente o padrão de fato em sistemas Linux protegidos e uma das distribuições corporativas mais difundidas do Red Hat Enterprise Linux (a partir do Red Hat Enterprise Linux 4). Depois disso, o SELinux começou a ser usado nos sistemas operacionais amplamente implementados Debian e Fedora e foi suportado pela distribuição Ubuntu, cuja popularidade aumentou (a partir do LTS versão 8.04 Hardy Heron). Muito mais tarde, a Novell (que estava desenvolvendo AppArmor na época e pretendia incluí-lo no kernel Linux) começou a suportar o SELinux nas distribuições OpenSUSE e SUSE Linux Enterprise.

No final, o Security-Enhanced Linux foi suportado por todos os desenvolvedores das distribuições mais utilizadas. No kernel Linux atual, versão 2.6, o SELinux usa o Linux Security Modules para operar. Além disso, muitos elementos do SELinux foram incorporados ao kernel propriamente dito.

O longo caminho percorrido para o desenvolvimento desse sistema de controle de acesso obrigatório foi supervisionado pela Agência de Segurança Nacional dos EUA. O trabalho básico de integrar o SELinux ao kernel Linux também foi suportado pela Red Hat. O website da NSA apresenta uma lista detalhada dos desenvolvedores que mais contribuíram para o desenvolvimento do SELinux (consulte Recursos).


Arquitetura do SELinux

Conforme o mencionado anteriormente, o sistema SELinux herdou a arquitetura do subsistema de segurança do Flask, um sistema operacional de pesquisa. O principal recurso do Flask era o uso do conceito de "menor privilégio" para fornecer aos usuários ou aplicativos somente os direitos de acesso necessários para a realização das ações solicitadas. Esse conceito é implementado usando o cumprimento de tipos (consulte Cumprimento de tipos). Graças a isso, o acesso obrigatório no SELinux funciona como parte do modelo do tipo de domínio. Neste modelo, cada sujeito do processo é ativado em um contexto de segurança (domínio) definido, ou seja, ele tem um determinado nível de acesso, ao passo que todos os objetos de recurso do sistema operacional (arquivos, diretórios, soquetes e outros) têm um determinado tipo (nível de sigilo) associado a eles.

Graças ao cumprimento de tipos, as opções de controle de acesso do SELinux superam amplamente as opções oferecidas pelo modelo discricionário básico usado nos sistemas do tipo® UNIX. Por exemplo, o SELinux pode ser usado para limitar estritamente o número de portas de rede que o servidor de rede pode acessar. Também pode permitir a criação de arquivos individuais e o salvamento de dados neles, mas não a exclusão, etc. Essa classificação dos objetos de sistema operacional ajuda a restringir os processos de sistema e de usuário usando um conjunto de direitos de acesso atribuídos claramente a recursos específicos. Se algum dos serviços controlados pelo SELinux for comprometido, o intruso não conseguirá ir além da Sandbox, que é restringida pelo conjunto de regras, nem mesmo com direitos de superusuário.

A lista de regras que define as permissões para que certos domínios acessem certos tipos também é uma política de segurança. A política de segurança é aplicada uma vez quando o sistema é configurado e consiste em um conjunto de arquivos de texto carregados na memória do kernel Linux durante a inicialização do sistema.

As regras estão em um formato legível para pessoas e podem ser entendidas até mesmo por usuários comuns. Por exemplo, na regra mostrada abaixo, referente ao servidor HTTP, é dada a permissão para ler alguns arquivos contendo a configuração de rede:

allow httpd_t net_conf_t:file { read getattr lock
ioctl };

O SELinux herdou do subsistema de segurança do Flask a estrutura e o princípio segundo o qual os rótulos operacionais definem o contexto de segurança dos sujeitos e objetos do sistema operacional, além do modelo do "tipo de domínio". Para garantir proteção total, é necessário definir os contextos de segurança para cada sujeito e objeto no sistema. Os rótulos têm a seguinte forma:

<user>:<role>:<type>

Por exemplo, o rótulo do contexto de segurança distribuído tem este formato: system_u:object_r:httpd_exec_t. No SELinux, o usuário system_u geralmente é o nome padrão dos daemons do sistema. A função object_r é atribuída a objetos do sistema, como dispositivos ou arquivos ordinários. O tipo httpd_exec_t é aplicado ao arquivo httpd em execução e está localizado no endereço /usr/sbin/httpd. Os elementos user, role e type serão abordados mais detalhadamente no próximo artigo.

Figura 1. Visão geral do sistema de controle de acesso obrigatório usando o SELinux

O SELinux abrange cinco componentes básicos:

  • Módulos auxiliares para operar com o sistema de arquivos
  • Módulos para interagir com o gancho de eventos do Linux Security Modules
  • Um mecanismo básico para organizar o controle de acesso
  • Policy Enforcement Server, um banco de dados de políticas de segurança do sistema
  • Access Vector Cache (AVC), um mecanismo auxiliar para aumentar a produtividade

A operação do SELinux está organizada da seguinte forma:

  1. O sujeito do sistema operacional (processo) tenta realizar uma determinada ação em um objeto específico (arquivo, processo, soquete), que é permitida dentro do sistema de segurança padrão discricionário do Linux (DAC). Isso ativa um fluxo de solicitações para o objeto.
  2. O Linux Security Modules intercepta todas as solicitações para realizar a ação com o objeto e as transfere, junto com o contexto de segurança do sujeito e do objeto, para o subsistema SELinux Abstraction & Hook Logic, responsável pela interação com o LSM.
  3. As informações recebidas do subsistema Abstraction and Hook Logic do SELinux são encaminhadas para o módulo básico Policy Enforcement Server, que é diretamente responsável por tomar a decisão de permitir o acesso do sujeito ao objeto.
  4. Para receber a decisão sobre a permissão ou proibição da ação, o servidor de cumprimento de políticas entra em contato com o subsistema especial Access Vector Cache, que muitas vezes armazena em cache as regras que estão sendo usadas.
  5. Se o AVC não contém a decisão em cache referente à política em questão, a solicitação da política de segurança necessária é encaminhada novamente para o banco de dados de políticas de segurança.
  6. Quando a política de segurança é localizada, ela é transferida para o servidor de políticas que recebe a decisão.
  7. Se a ação solicitada cumpre a política localizada, a operação é permitida. Caso contrário, ela é proibida, e todas as informações de tomada de decisão são gravadas no arquivo de log do SELinux.

Além de tomar a decisão de permitir ou proibir certas ações, o módulo Policy Enforcement Server também é responsável por realizar tarefas auxiliares, como o gerenciamento de rótulos de segurança (alocação, remoção).

Como acontece nos sistemas excelentes, a simplicidade da operação do SELinux deve garantir uma operação confiável, baixa demanda de recursos e um bom nível de produtividade de todo o sistema de controle de acesso obrigatório.


Conclusão

Este artigo da série "Linux Seguro" começa com uma explicação sobre o Security-Enhanced Linux—, o melhor e mais eficiente sistema de controle de acesso obrigatório usado nos sistemas operacionais GNU/Linux.

O SELinux merece a reputação de sistema confiável de proteção da segurança. O renome da Agência de Segurança Nacional dos EUA, que criou e desenvolveu o SELinux, contribuiu muito para isso. Entretanto, além da importante contribuição da NSA, o SELinux também se baseia em vários anos de desenvolvimento científico na área de segurança de sistemas de TI. Esse desenvolvimento teve uma base teórica profunda e provou ser altamente efetivo na prática, em sistemas militares especializados.

No entanto, o uso do SELinux em redes corporativas ou PCs domésticos não é tão simples assim. O SELinux está relacionado a sistemas de controle obrigatório de acesso baseados em rótulos. Isso significa que cada objeto e sujeito do sistema operacional deve ter um rótulo e— um contexto de segurança atribuídos a ele. Finalmente, uma boa política de segurança do SELinux para o sistema inteiro contém, em média, mais de 100 mil regras! Consequentemente a sua criação, o refinamento e a manutenção, na sua forma atual, requer muito tempo e esforço. Na verdade, a criação de uma política de segurança desse tipo, a partir do zero, para um sistema de computador existente ou planejado só se justifica em pouquíssimos casos. Por exemplo, se a natureza dos dados armazenados e processados requer confiabilidade e proteção excepcionais do servidor. Os críticos do sistema dizem que o SELinux só é impenetrável, do ponto de vista da segurança de TI, devido à sua complexidade. Por exemplo, se um invasor conseguisse passar pelas defesas do sistema, a desculpa para isso seria a configuração incorreta do SELinux por parte do administrador.

Ao tentar criar regras de acesso para qualquer programa específico, o administrador também pode encontrar ações que ignoram as restrições do SELinux. Por exemplo, alguns aplicativos no Linux alternam parcialmente entre os direitos de superusuário e os de usuário comum, ou seja, tentam aplicar o princípio de menor privilégio. Os direitos do superusuário, na verdade, só são usados quando isso é absolutamente necessário. Entretanto, não é fácil descrever esse comportamento como parte do modelo de segurança do SELinux.

Entretanto, o progresso continua, e todos esses problemas estão sendo estudados pelos desenvolvedores. Foram criados alguns conjuntos de regras que podem ser usados em situações típicas em servidores e PCs domésticos: o administrador do sistema só precisa selecionar uma das políticas de segurança prontas para uso e reinicializar o computador com o SELinux ativado.

O próprio SELinux também está sendo aprimorado constantemente, tanto por meio da criação e desenvolvimento de políticas de segurança quanto pela interação com desenvolvedores e a modificação dos programas já existentes.

Artigos adicionais na série "Linux Seguro" descrevem detalhadamente o uso do SELinux na prática. Esse uso envolve a criação e o refinamento de regras, o controle do comportamento do SELinux e a resolução de possíveis problemas.

Recursos

Aprender

Obter produtos e tecnologias

  • Avalie produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto online, use-o em um ambiente de nuvem ou passe algumas horas no no Ambiente de Simulação da SOA para saber mais sobre como implementar arquitetura orientada a serviço (SOA) de maneira eficiente.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Software livre
ArticleID=828882
ArticleTitle=Linux Seguro: Parte 1. SELinux – história de seu desenvolvimento, arquitetura e princípios operacionais
publish-date=05162014