Anatomia do Security-Enhanced Linux (SELinux)

Arquitetura e Implementação

O Linux® tem sido descrito como um dos sistemas operacionais mais seguros disponíveis, mas a Agência de Segurança Nacional (NSA) levou-o a um nível mais alto, com a introdução do Security-Enhanced Linux (SELinux). O SELinux toma o sistema operacional GNU/Linux já existente e o estende com modificações no kernel e no espaço do usuário, deixando-o invulnerável. Se hoje você estiver executando um kernel 2.6, talvez se surpreenda ao saber que neste momento está utilizando o SELinux! Este artigo explora as ideias por trás do SELinux e como ele é implementado.

M. Tim Jones, Consultant Engineer, Emulex Corp.

M. Tim JonesM. Tim Jones é um arquiteto de firmwares embarcados e autor de Inteligência Artificial: Sistemas de Abordagem, GNU/Linux, Programação de Aplicativos AI (atualmente em sua segunda edição), Programação de Aplicativos AI (em sua segunda edição) e BSD Sockets Programming from a Multilanguage Perspective. Sua formação em engenharia vai desde o desenvolvimento de kernels para nave espacial geossincrônica até a arquitetura de sistema embarcado e o desenvolvimento de protocolos de interligação de redes. Tim é um Engenheiro Consultor para a Emulex Corp. em Longmont, Colorado.


nível de autor Contribuidor do
        developerWorks

29/Abr/2008

Introdução

Redes públicas como a Internet são locais perigosos. Qualquer um com um computador conectado à Internet (mesmo provisoriamente) compreende esses perigos. Invasores podem explorar as falhas de segurança para obter acesso a um sistema a fim de obter acesso não autorizado a informações ou converter um computador para enviar spam ou participar de ataques a outros sistemas high-profile (utilizando SYN floods como parte de ataques chamados Distributed Denial of Service).

Os ataques Distributed Denial of Service (DDoS) são orquestrados a partir de vários sistemas ao longo da Internet (os assim chamados computadores zumbis) para consumir os recursos no sistema de destino e inutilizá-lo para os usuários legítimos (explorando o handshake de três vias do TCP)). Para informações adicionais sobre um protocolo que remove este recurso utilizando um handshake de quatro vias e cookies (Stream Control Transmission Protocol [SCTP]), consulte a seção Recursos.

A Origem do SELinux

O SELinux é um produto do governo e da indústria, com design e desenvolvimento fornecidos pela NSA, Network Associates, Tresys e muitas outras. Embora tenha sido introduzido pela NSA como um conjunto de correções, foi inoculado no kernel Linux 2.6.

O GNU/Linux é bastante seguro, mas também bastante dinâmico: podem aparecer alterações que furem o sistema operacional, e estes podem ser explorados. Embora se dê atenção considerável à prevenção do acesso não autorizado, o que acontece após uma entrada?

Este artigo explora as ideias por trás do SELinux e sua arquitetura básica. Uma visão geral completa do SELinux poderia ser o tópico de um livro inteiro (consulte a seção Recursos), assim, este artigo mantém-se nos fundamentos para dar uma ideia sobre o porquê da importância do SELinux e como ele é implementado.

Métodos de Controle de Acesso

A maioria dos sistemas operacionais utiliza controles de acesso para determinar se uma entidade (usuário ou programa) pode acessar um determinado recurso. Sistemas baseados em UNIX® utilizam uma forma de Discretionary Access Control (DAC). Esse método restringe o acesso a objetos baseados normalmente nos grupos aos quais pertencem. Como exemplos, os arquivos no GNU/Linux têm um proprietário, um grupo e um conjunto de permissões. As permissões definem quem pode acessar um determinado arquivo, quem pode lê-lo, gravar nele e executá-lo. Essas permissões são divididas em três conjuntos de usuários, representando o usuário (proprietário do arquivo), o grupo (todos os usuários membros de um grupo) e outros (todos os usuários que não sejam nem membros do grupo nem proprietários do arquivo).

Agrupar controles de acesso dessa maneira cria um problema, pois um programa explorado herda os controles de acesso do usuário. E pode, assim, fazer coisas no nível do acesso do usuário, o que não é desejável. Em vez de definir restrições dessa maneira, é mais seguro utilizar o princípio do privilégio mínimo: programas podem fazer o que precisam para executar suas tarefas, e nada além disso. Por exemplo, se você tiver um programa que responde a pedidos de soquete, mas não precisa de acesso ao sistema de arquivos, esse programa deverá ser capaz de atender a um determinado soquete, mas não terá acesso ao sistema de arquivo. Assim, se o programa for explorado de alguma forma, seu acesso será explicitamente reduzido. Esse tipo de controle é chamado de Mandatory Access Control (MAC).

Outra abordagem ao controle de acesso é o Role-based Access Control (RBAC). No RBAC, as permissões são fornecidas com base em regras concedidas pelo sistema de segurança. O conceito de regra difere daquele de um grupo tradicional, no sentido de que o grupo representa um ou mais usuários. Uma regra pode representar diversos usuários, mas também representa as permissões que um conjunto de usuários pode desempenhar.

O SELinux inclui o MAC e o RBAC no sistema operacional GNU/Linux. A seção seguinte explora a implementação do SELinux e como a execução da segurança foi incluída com transparência no kernel Linux.


Implementação de Segurança do Linux

Nos primórdios do SELinux, quando ainda era um conjunto de atualizações, ele fornecia a própria estrutura de segurança. Isso era problemático, porque deixava o GNU/Linux preso a uma única arquitetura de controle de acesso. Em vez de adotar uma única abordagem, o kernel Linux herdou uma estrutura genérica, que separava a política de execução. Essa solução foi a estrutura do Linux Security Module (LSM). O LSM fornece uma estrutura polivalente em termos de segurança, que permite aos modelos de segurança serem implementados como módulos de kernel carregáveis (consulte a Figura 1).

Figura 1. Política de Segurança e Execução São Independentes Utilizando o SELinux.
Figura 1. Política de Segurança e Execução São Independentes Utilizando o SELinux.

O código do kernel é modificado antes de acessar objetos internos para chamar um gancho que represente uma função de execução, o qual implementa a política de segurança. Esta função valida que a operação pode continuar com base nas políticas predefinidas. As funções de segurança são armazenadas em uma estrutura de operações de segurança que abrange as operações fundamentais, que devem ser protegidas. Por exemplo, o gancho security_socket_create (security_ops->socket_create) verifica as permissões antes de criar um novo soquete e considera a família de protocolos, o tipo, o protocolo e se o soquete é criado no kernel ou no espaço do usuário. A Lista 1 fornece uma amostra do código a partir de socket.c para a criação do soquete (consulte ./linux/net/socket.c).

Lista 1. Código do Kernel para a Criação de Soquete
static int __sock_create(int family, int type, int protocol,
                          struct socket **res, int kern)
{
        int err;
        struct socket *sock;

        /*
         *      Verificar se o protocolo está no intervalo
         */
        if (family < 0 || family >= NPROTO)
                return -EAFNOSUPPORT;
        if (type < 0 || type >= SOCK_MAX)
                return -EINVAL;

err = security_socket_create(family, type, protocol, kern);
        if (err)
                return err;

        ...

A função security_socket_create é definida em ./linux/include/linux/security.h. Ela fornece caminhos indiretos a partir da chamada security_socket_create até a função dinamicamente instalada na estrutura security_ops (consulte Lista 2).

Lista 2. Chamada Indireta para Verificação de Criação do Soquete
static inline int security_socket_create (int family, int type,
                                          int protocol, int kern)
{
        return security_ops->socket_create(family, type, protocol, kern);
}

A função na estrutura security_ops é instalada pelo módulo de segurança. Neste caso, os ganchos são definidos para o SELinux no módulo do kernel carregável. Cada chamada de SELinux é definida dentro do arquivo de ganchos que completa os caminhos indiretos, da função do kernel até a chamada dinâmica para o módulo de segurança específico (consulte a Lista 3 de .../linux/security/selinux/hooks.c).

Lista 3. A Verificação de Criação do Soquete SELinux
static int selinux_socket_create(int family, int type,
                                 int protocol, int kern)
{
        int err = 0;
        struct task_security_struct *tsec;

        if (kern)
                goto out;

        tsec = current->security;
        err = avc_has_perm(tsec->sid, tsec->sid,
                           socket_type_to_security_class(family, type,
                           protocol), SOCKET__CREATE, NULL);

out:
        return err;
}

No núcleo da Lista 3 está a chamada que valida se a operação atual será permitida para a tarefa atual (conforme definido por current->security, em que current representa a tarefa em execução no momento). O Access Vector Cache (AVC) é um cache das decisões anteriores do SELinux (para aumentar o desempenho do processo). Essa chamada inclui o identificador de segurança de origem (sid), a classe de segurança (construída a partir dos detalhes da operação solicitada), a chamada do soquete específica e os dados de auditoria opcionais auxiliares. Se a decisão não foi encontrada no cache, o servidor de segurança é chamado para tomar a decisão (esse processo é mostrado na Figura 2).

Figura 2. Processo de Segurança do Linux em Camada
Figura 2. Processo de Segurança do Linux em Camada

Os ganchos de retorno de chamada inicializados no security_ops são definidos dinamicamente como um módulo de kernel carregável (através de register_security()) mas, por outro lado, contêm funções stub dummy quando nenhum módulo de segurança está carregado (consulte ./linux/security/dummy.c). Estas funções stub implementam a política padrão do DAC Linux. Existem ganchos de retorno de chamada em todos os pontos onde a mediação de objetos deve ser fornecida para a segurança. Isso inclui o gerenciamento de tarefas (criação, sinalização, espera), carregamento de programas (execve), gerenciamento de sistema de arquivos (superblock, inode e filehooks), IPC (filas de mensagens, memória compartilhada e operações de semáforo), ganchos de módulo (inserção e remoção) e ganchos de rede (abrangendo soquetes, netlink, dispositivos de rede e outras interfaces de protocolo). Saiba mais sobre os vários ganchos na seção Recursos ou revisando o arquivo security.h.

Gerenciar as políticas do SELinux está muito além do escopo deste artigo, mas é possível obter informações adicionais sobre a configuração do SELinux na seção Recursos.


Outras Abordagens

O SELinux é uma das estruturas de segurança mais abrangentes disponíveis hoje, mas com certeza não é a única. Esta seção examina algumas outras abordagens disponíveis.

AppArmor

O AppArmor, originalmente desenvolvido pela Immunix e depois mantida pela Novell, é uma alternativa ao SELinux que também usa a estrutura do Módulo de Segurança Linux (LSM). Como SELinux e AppArmor utilizam a mesma estrutura, podem ser trocados. AppArmor foi originalmente desenvolvido porque achava-se que o SELinux era complexo demais para que usuários típicos o gerenciassem. Ele inclui um modelo MAC totalmente configurável, assim como um modo de aprendizagem no qual o comportamento típico de um programa pode ser transformado em um perfil.

Um problema com o SELinux é que ele exige um sistema de arquivos que possa oferecer suporte a atributos estendidos; AppArmor, porém, só utiliza sistema de arquivos agnósticos. É possível encontrar AppArmor em SUSE, em OpenSUSE, e agora em Gutsy Gibbon de Ubuntu.

Solaris 10 (antes Trusted Solaris)

O sistema operacional Solaris 10 fornece controles de acesso obrigatórios por meio de seu componente Trusted Extensions aprimorado pela segurança. Ele também é fornecido para MAC e RBAC. O Solaris obtém essa condição incluindo rótulos de sensibilidade a todos os objetos, fornecendo a você controle sobre dispositivos, arquivos, acesso a rede e mesmo a serviços de gerenciamento de janelas. A vantagem de RBAC no Solaris 10 minimiza a necessidade de acesso à raiz, fornecendo controle refinado sobre as tarefas administrativas que podem, assim, ser atribuídas.

TrustedBSD

O TrustedBSD é um projeto em andamento para desenvolver extensões confiáveis de sistema operacional destinadas, em última análise, ao sistema operacional FreeBSD. Ele inclui controle obrigatório de acesso criado no topo da arquitetura de segurança Flux Advanced Security Kernel (Flask), incluindo execução de tipo e segurança em vários níveis (MLS), todos como módulos de plug-in. O TrustedBSD também incorpora a implementação de auditoria de software livre do Basic Security Module (BSM) do sistema operacional Darwin da Apple (embora o BSM tenha sido originalmente introduzido pela Sun). O BSM é uma API de auditoria e um formato de arquivo que oferece suporte a processos generalizados de rastreio de auditoria. O BSD confiável também forma a estrutura utilizada pelo Security Enhanced Darwin (SEDarwin).

Virtualização do Sistema Operacional

Uma opção final para aumentar a segurança em sistemas operacionais é a virtualização do sistema operacional (também chamada de servidores virtuais privados). Um único sistema operacional hospeda diversas instâncias isoladas de espaços do usuário como forma de separar a funcionalidade. A virtualização do sistema operacional também restringe as capacidades dos aplicativos que executam nos espaços de usuário isolados. Por exemplo, uma instância de espaço de usuário pode não modificar o kernel (módulos de carregamento ou remoção do kernel) nem montar ou desmontar sistemas de arquivos. Também não é permitido modificar os parâmetros do kernel (por exemplo, por meio do sistema de arquivos proc). Nada que possa modificar o ambiente de outras instâncias de usuário é permitido.

A virtualização do sistema operacional está disponível em muitos sistemas operacionais. O GNU/Linux oferece suporte a VServer, Parallels Viruozzo Containers, e OpenVZ. Em outros sistemas operacionais, é possível encontrar contêineres (Solaris) e gaiolas (BSD). No Linux-VServer, cada instância de espaço de usuário individual é denominada contexto de segurança. Em cada contexto de segurança é iniciado um novo init para a instância privada do servidor. Saiba mais sobre virtualização do sistema operacional e outros métodos de virtualização na seção Recursos.


Indo Além

Controle de acesso obrigatório e controle de acesso baseado em regras são relativamente novos no kernel Linux. Com a introdução da estrutura LSM, novos módulos de segurança certamente serão disponibilizados. Além dos aprimoramentos à estrutura, é possível empilhar módulos de segurança, permitindo a coexistência de vários deles e fornecendo cobertura máxima para as necessidades de segurança do Linux. Também serão introduzidos novos métodos de controle de acesso conforme a pesquisa sobre segurança no sistema operacional prossegue. Para uma introdução detalhada às atuais ofertas LSM e SELinux, consulte os artigos e documentos na seção Recursos.

Recursos

Aprender

Obter produtos e tecnologias

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
ArticleID=382586
ArticleTitle=Anatomia do Security-Enhanced Linux (SELinux)
publish-date=04292008