Pesquisa de site

Implementando controle de acesso obrigatório com SELinux ou AppArmor no Linux


Para superar as limitações e aumentar os mecanismos de segurança fornecidos pelas permissões padrão ugo/rwx e pelas listas de controle de acesso, a Agência de Segurança Nacional dos Estados Unidos (NSA) desenvolveu uma Agência de Segurança Nacional dos Estados Unidos (NSA) criou uma Agência de Segurança Nacional dos Estados Unidos (NSA) flexível. Strong>Método de controle de acesso obrigatório (MAC) conhecido como SELinux (abreviação de Security Enhanced Linux) para restringir, entre outras coisas, a capacidade dos processos de acessar ou realizar outras operações em objetos do sistema (como arquivos, diretórios, portas de rede, etc.) com a menor permissão possível, permitindo ainda modificações posteriores neste modelo.

Outro MAC popular e amplamente utilizado é o AppArmor, que além dos recursos fornecidos pelo SELinux, inclui um modo de aprendizagem que permite ao sistema “aprender forte> ”como um aplicativo específico se comporta e definir limites configurando perfis para uso seguro do aplicativo.

No CentOS 7, o SELinux é incorporado ao próprio kernel e é habilitado no modo Enforcing por padrão (mais sobre isso na próxima seção), ao contrário do openSUSE e do Ubuntu que usam o AppArmor.

Neste artigo explicaremos os fundamentos do SELinux e AppArmor e como usar uma dessas ferramentas para seu benefício dependendo da distribuição escolhida.

Introdução ao SELinux e como usá-lo no CentOS 7

O Security Enhanced Linux pode operar de duas maneiras diferentes:

  1. Aplicação: o SELinux nega acesso com base nas regras de política do SELinux, um conjunto de diretrizes que controlam o mecanismo de segurança.
  2. Permissivo: o SELinux não nega acesso, mas as negações são registradas para ações que seriam negadas se estivessem sendo executadas no modo de imposição.

SELinux também pode ser desabilitado. Embora não seja um modo de operação em si, ainda é uma opção. Porém, aprender a usar essa ferramenta é melhor do que simplesmente ignorá-la. Tenha isso em mente!

Para exibir o modo atual do SELinux, use getenforce. Se você quiser alternar o modo de operação, use setenforce 0 (para defini-lo como Permissivo) ou setenforce 1 (Aplicativo forte>).

Como esta alteração não sobreviverá a uma reinicialização, você precisará editar o arquivo /etc/selinux/config e definir a variável SELINUX como aplicativo, permissivo ou desativado para obter persistência nas reinicializações:

Além disso, se getenforce retornar Disabled, você terá que editar /etc/selinux/config com o modo de operação desejado e reinicializar. Caso contrário, você não poderá definir (ou alternar) o modo de operação com setenforce.

Um dos usos típicos de setenforce consiste em alternar entre os modos do SELinux (de aplicativo para permissivo ou vice-versa) para solucionar problemas de um aplicativo que está se comportando mal ou não está funcionando conforme o esperado. Se funcionar depois de definir o SELinux para o modo Permissivo, você pode ter certeza de que está enfrentando um problema de permissões do SELinux.

Dois casos clássicos em que provavelmente teremos que lidar com o SELinux são:

  1. Alterando a porta padrão onde um daemon escuta.
  2. Configurando a diretiva DocumentRoot para um host virtual fora de /var/www/html.

Vamos dar uma olhada nesses dois casos usando os exemplos a seguir.

EXEMPLO 1: Alterando a porta padrão para o daemon sshd

Uma das primeiras coisas que a maioria dos administradores de sistema faz para proteger seus servidores é alterar a porta onde o daemon SSH escuta, principalmente para desencorajar scanners de porta e invasores externos. Para fazer isso, usamos a diretiva Port em /etc/ssh/sshd_config seguida pelo novo número da porta como segue (usaremos a porta 9999 neste caso):


Port 9999

Depois de tentar reiniciar o serviço e verificar seu status, veremos que ele falhou ao iniciar:


systemctl restart sshd
systemctl status sshd

Se dermos uma olhada em /var/log/audit/audit.log, veremos que o sshd foi impedido de iniciar na porta 9999 pelo SELinux porque essa é uma porta reservada para o serviço JBoss Management (as mensagens de log do SELinux incluem a palavra “AVC” para que possam ser facilmente identificados em outras mensagens):


cat /var/log/audit/audit.log | grep AVC | tail -1

Neste ponto, a maioria das pessoas provavelmente desativaria o SELinux, mas nós não o faremos. Veremos que existe uma maneira de o SELinux e o sshd ouvirem em uma porta diferente viverem em harmonia. Certifique-se de ter o pacote policycoreutils-python instalado e execute:


yum install policycoreutils-python

Para ver uma lista das portas onde o SELinux permite que o sshd escute. Na imagem a seguir também podemos ver que a porta 9999 foi reservada para outro serviço e portanto não podemos usá-la para executar outro serviço por enquanto:


semanage port -l | grep ssh

É claro que poderíamos escolher outra porta para SSH, mas se tivermos certeza de que não precisaremos usar esta máquina específica para nenhum serviço relacionado ao JBoss, podemos então modificar a regra SELinux existente e atribuir essa porta ao SSH:


semanage port -m -t ssh_port_t -p tcp 9999

Depois disso, podemos usar o primeiro comando semanage para verificar se a porta foi atribuída corretamente, ou as opções -lC (abreviação de list custom):


semanage port -lC
semanage port -l | grep ssh

Agora podemos reiniciar o SSH e conectar-se ao serviço usando a porta 9999. Observe que essa alteração sobreviverá a uma reinicialização.

EXEMPLO 2: Escolhendo um DocumentRoot fora de /var/www/html para um host virtual

Se você precisar configurar um host virtual Apache usando um diretório diferente de /var/www/html como DocumentRoot (digamos, por exemplo, /websrv/sites /gabriel/public_html):


DocumentRoot “/websrv/sites/gabriel/public_html”

O Apache se recusará a fornecer o conteúdo porque o index.html foi rotulado com o tipo default_t SELinux, que o Apache não pode acessar:


wget http://localhost/index.html
ls -lZ /websrv/sites/gabriel/public_html/index.html

Assim como no exemplo anterior, você pode usar o seguinte comando para verificar se este é realmente um problema relacionado ao SELinux:


cat /var/log/audit/audit.log | grep AVC | tail -1

Para alterar o rótulo de /websrv/sites/gabriel/public_html recursivamente para httpd_sys_content_t, faça:


semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

O comando acima concederá ao Apache acesso somente leitura a esse diretório e seu conteúdo.

Por fim, para aplicar a política (e fazer com que a alteração do rótulo tenha efeito imediato), faça:


restorecon -R -v /websrv/sites/gabriel/public_html

Agora você deve conseguir acessar o diretório:


wget http://localhost/index.html

Para obter mais informações sobre o SELinux, consulte o guia Fedora 22 SELinux e Administrador.


Todos os direitos reservados. © Linux-Console.net • 2019-2024