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.

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.

Voltar para parte superior

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).

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).

                
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).

                
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).

                
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).

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.

Voltar para parte superior

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.

Voltar para parte superior

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

• Verifique a Web site NSA para SELinux para obter muitas informações sobre as ideias por trás de SELinux. Este site dá detalhes sobre projetos relacionados que resultaram no SELinux, assim como um ótimo conjunto de documentos e apresentações técnicos sobre segurança referentes ao SELinux.
  
  
• Consulte Better Networking with SCTP (developerWorks, fevereiro de 2006) para informações sobre proteção na inicialização. O TCP tem um problema conhecido com o handshake de três vias, que pode permitir ataques Denial of Service, que consomem recursos e derrubam um sistema (de uma perspectiva externa de conectividade). O SCTP soluciona isso com o handshake de quatro vias.
  
  
• Na Wikipedia há uma introdução ótima aos métodos de controle de acesso que inclui tanto o acesso físico como a segurança do computador. Você também encontrará detalhes sobre os três métodos de controle de acesso discutidos aqui, inclusive Controle de Acesso Discricionário, Controle de Acesso Obrigatório e Controle de Acesso Baseado em Funções.
  
  
• O SELinux conta com a Estrutura do Módulo de Segurança do Linux. para fornecer as chamadas de execução das chamadas do kernel padrão. Esse documento sobre o LSM fornece detalhes consideráveis sobre o LSM e o escopo de sua implementação.
  
  
• O LSM é uma implementação parcial da arquitetura de segurança Flask, desenvolvida originalmente para o sistema operacional Fluke do microkernel. Saiba mais sobre Flask, Flux e Fluke no Web site da Universidade de Utah.
  
  
• Leia Comando Kernel Utilizando Chamadas do Sistema Linux (developerWorks, março de 2007) para obter informações adicionais sobre a implementação das chamadas de sistema no kernel Linux. Este artigo explora a implementação das chamadas de sistema, assim como a forma de incluir novas chamadas de sistema no kernel. Saiba mais sobre o kernel Linux e sua arquitetura em Anatomia do Kernel Linux (developerWorks, junho de 2007).
  
  
• O site NSA tem uma introdução ótima à configuração da política do SELinux, abrangendo tópicos introdutórios até detalhes de configuração. O gerenciamento de políticas é um dos aspectos mais complexos do SELinux, mas, felizmente, existe bastante documentação disponível, assim como configurações-padrão, com as quais é possível trabalhar. A Tresys Technology também fornece uma página útil sobre a Política de Referência do SELinux, que inclui muito mais informações sobre o SELinux.
  
  
• AppArmor é outro modulo de segurança baseado no LSM. Você encontrará suporte para AppArmor em inúmeros sistemas operacionais, inclusive openSUSE e Ubuntu. Até recentemente, Novell era o principal desenvolvedor, mas a empresa dispensou sua equipe do AppArmor.
  
  
• Nesta visão geral da arquitetura do Solaris Trusted, leia mais sobre o Extensions (parte do sistema operacional Solaris 10). Este documento fornece uma introdução prática à abordagem do Solaris quanto ao aprimoramento de segurança. Há mais informações na página do Solaris Trusted Extensions.
  
  
• TrustedBSD compartilha muitos dos objetivos do SELinux junto a alguns elementos específicos de design (como a arquitetura de segurança Flask). A implementação do TrustedBSD também é compartilhada com o sistema operacional Security Enhanced Darwin.
  
  
• Leia Linux Virtual (developerWorks, dezembro de 2006) para rever os métodos de virtualização, incluindo a virtualização do sistema operacional. Esse artigo o introduzirá aos vários métodos de virtualização e seu histórico. A Wikipedia também mantém uma introdução à virtualização do sistema operacional , inclusive com uma comparação entre as várias implementações.
  
  
• Na zona Linux do developerWorks, encontre mais recursos para desenvolvedores Linux e varra nossos artigos e tutoriais mais conhecidos.
  
  
• Consulte todas as dicas de Linux e tutoriais de Linux no developerWorks.
  
  
• Fique atualizado com eventos técnicos e Webcasts do developerWorks.
  
  

Obter produtos e tecnologias

• Solicite o SEK para Linux, um conjunto de dois DVDs que contém o software de período experimental IBM mais recente para Linux a partir do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  
• Com o Software de período experimental IBM, disponível para download diretamente do developerWorks, construa seu próximo projeto de desenvolvimento em Linux.
  
  

Discutir

• Envolva-se com a comunidade do developerWorks através de blogs, fóruns, podcasts e tópicos da comunidade em nossos novos espaços do developerWorks.
  
  

Sobre o autor

M. 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.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Métodos de Controle de Acesso
• Implementação de Segurança do Linux
• Outras Abordagens
• Indo Além
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais