Customizando Políticas de Segurança SELinux

O conceito de política modular no SELinux permite que desenvolvedores e fornecedores de aplicativos empacotem junto com o próprio aplicativo o módulo de segurança que permitirá a execução dos aplicativos em um ambiente protegido pelo SELinux. A política modular também permite aos administradores do sistema realizar mudanças locais na política de forma mais simples e sem a preocupação com atualizações da política de segurança. A ferramenta utilizada para gerenciar os módulos de política SELinux é o semodule. Ele realiza instalação, atualização, listagem e remoção de módulos de política. Também pode ser usado para reconstrução de uma política ou para recarregar a política sem realizar nenhuma outra transação (como na atualização on-line da política de segurança, por exemplo). o semodule atua em pacotes de módulos de políticas criados pelo semodule_package. Convencionalmente, esses arquivos possuem o sufixo ``.pp'' (policy package).

Para verificar os módulos de políticas SELinux instalados, é realizado o comando:

Por exemplo de customização da política, vamos supor que o script de inicialização do daemon ypbind execute o comando setsebool que tenta usar o terminal e irá gerar a seguinte entrada no log:

Para eliminar essa entrada AVC, pode ser utilizado o programa audit2allow para gerar uma regra como essa:

A partir do Fedora 5 e Red Hat Enterprise Linux 5, o programa audit2allow recebeu a possibilidade de construir módulos de políticas que podem ser utilizadas para personalizar a política local utilizada:

O programa audit2allow irá criar um arquivo do tipo type enforcement (mysemanage.te), depois irá executar o comando checkmodule para compilar o arquivo do módulo (mysemanage.mod). Então ele usa o programa semodule_package para criar o pacote da política (mysemanage.pp), e após o comando semodule irá carregar a política no kernel. As mudanças na política serão permanentes e irão sobreviver a reinicializações da máquina. O arquivo pacote da política mysemanage.pp pode ser copiado para outras máquinas e instalado usando semodule.

Para entender como a política foi construída, o arquivo mysemanage.te deverá ser verificado. No exemplo ele terá o seguinte conteúdo:

O arquivo mysemanage.te possuirá três sessões. A primeira sessão identifica o nome do módulo, que deverá ser único no sistema, e sua versão. Se for usado o mesmo nome de algum outro módulo já utilizado, o módulo da política atual será substituído, caso o número da versão for maior que o atual. A proxima sessão do arquivo é o bloco ``require'', que é usado para dizer ao carregador da política semodule qual tipo, classes e papéis são requeridos na política do sistema antes que este módulo possa ser instalado. Se qualquer um desses campos estiverem indefinidos, o comando semodule irá falhar. A última sessão é das regras de allow. Nesse caso específico, a linha pode ser mudada para ``dontaudit'', uma vez que o semodule não precisa ter acesso ao file descriptor (fd). Por isso é necessário o conhecimento do aplicativo em si e de como as políticas SELinux são construídas, pois apesar do audit2allow facilitar muito a criação de políticas SELinux, ele pode acabar liberando muita coisa sem necessidade, diminuindo a segurança e indo contra ao princípio de menor privilégio.