Políticas Modulares

Até o Linux Fedora Core 4, o arquivo de política SELinux deveria ser monolítico, ou seja, a política é construída em um único binário pelo checkpolicy e diretamente carregado no kernel. O problema dessa abordagem usando políticas monolíticas é que as políticas SELinux são frequentementes grandes e complexas, e além disso, se a política fosse alterada era necessário pegar todo código fonte da política, modificá-lo e depois compilá-lo. Em vista disso, a partir do Linux Fedora Core 5 as políticas foram modificas para serem separadas em pequenas unidades chamadas de módulos. Isso significa que desenvolvedores terceiros podem embarcar módulos de políticas SELinux junto com suas aplicações, e eles podem fazer isso sem ter que lidar com todo o código restante da política. Isso atualmente funciona separando-se os passos de compilação e link-edição no procedimento de compilação da política. Módulos de política são compilados dos códigos fonte, e linkados quando instalados no ``armazém de módulos''. Essa política linkada é então carregada no kernel para ser aplicada.

O comando primário para lidar com módulos SELinux é o semodule, que permite instalar, atualizar e remover módulos. Outros comandos úteis são: checkmodule, que é o compilador de módulos incluído no pacote do checkpolicy; e o semodule_package, que cria um arquivo de pacote da política (.pp) de um módulo de política compilado. Módulos geralmente são armazenados como um arquivo de pacote da política (extensão .pp) no diretório /usr/share/selinux/$POLITICA/. Lá deve existir pelo menos o arquivo base.pp, que é o módulo básico.

Abaixo seguem os arquivos que compõem o código fonte de um módulo exemplo extraído da Política de Referência SELinux [PEBENITO 2006], aplicado ao serviço BIND (DNS):

• bind.te: contém a política privada completa para o domínio ``named''. A macro ``policy_module()'' contém o nome e a versão do módulo que serão usados para carregar os módulos de políticas. As próximas nove linhas contém as declarações de tipos e as chamadas de transformações de macro. O tipo para o domínio e seu programa de ponto de entrada são declarados e transformados usando a macro ``init_daemon_domain()'', a qual é uma interface para o módulo da política do init. O restante da política privada contém as regras para o serviço BIND. Para acessos aos tipos que não estão nesse módulo, existem nove chamadas para interfaces de outros módulos, como por exemplo ``logging_send_syslog_msg()'' é uma interface do módulo de log que permite que o BIND envie mensagens ao serviço de log.
  

• bind.if: as interfaces públicas do módulo são definidas nesse arquivo. Nesse módulo exemplo, o uso da macro ``interface()'' define o acesso de entrada para o domínio ``named'' (como por exemplo, uma transição de domínios). O chamador deverá prover o tipo que ele quer ter acesso para entrar nesse domínio ``named''. O arquivo de interfaces também possui uma documentação disponibilizada no formato XML para ser lida por ferramentas de análise ou de desenvolvimento.
  

• bind.fc: contém os contextos dos arquivos. Para facilitar o uso de políticas MLS ou MCS, a macro ``gen_context()'' foi adicionada. O contexto regular é especificado no primeiro parâmetro, o segundo parâmetro mostra o nível de segurança do arquivo quando uma política MLS é utilizada. O terceiro parâmetro é opcional e especifica as categorias do arquivo quando é utilizada a política MCS, isso possibilita a mudança de políticas MLS para políticas que não sejam MLS, sem modificar a política.