Pesquisa de site

Série RHCSA: Fundamentos de controle de acesso obrigatório com SELinux no RHEL 7 - Parte 13


Durante esta série, exploramos detalhadamente pelo menos dois métodos de controle de acesso: permissões padrão ugo/rwx (Gerenciar usuários e grupos – Parte 3) e listas de controle de acesso (Configurar ACLs em sistemas de arquivos – Parte 7).

Embora sejam necessários como permissões de primeiro nível e mecanismos de controle de acesso, eles têm algumas limitações que são abordadas pelo Security Enhanced Linux (também conhecido como SELinux, para abreviar).

Uma dessas limitações é que um usuário pode expor um arquivo ou diretório a uma violação de segurança através de um comando chmod mal elaborado e, assim, causar uma propagação inesperada de direitos de acesso. Como resultado, qualquer processo iniciado por esse usuário pode fazer o que quiser com os arquivos de propriedade do usuário, onde, finalmente, um software malicioso ou comprometido de outra forma pode obter acesso de nível raiz a todo o sistema.

Com essas limitações em mente, a Agência de Segurança Nacional dos Estados Unidos (NSA) primeiro desenvolveu o SELinux, um método flexível de controle de acesso obrigatório, para restringir o capacidade dos processos de acessar ou realizar outras operações em objetos do sistema (como arquivos, diretórios, portas de rede, etc.) para o modelo de menor permissão, que pode ser modificado posteriormente conforme necessário. Em poucas palavras, cada elemento do sistema recebe apenas o acesso necessário para funcionar.

No RHEL 7, o SELinux é incorporado ao próprio kernel e é ativado no modo Enforcing por padrão. Neste artigo explicaremos brevemente os conceitos básicos associados ao SELinux e seu funcionamento.

Modos SELinux

O SELinux pode operar de três 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.
  3. Desativado (autoexplicativo).

O comando getenforce exibe o modo atual do SELinux, enquanto setenforce (seguido por um 1 ou um 0) é usado para alterar o modo para Aplicativo ou Permissivo, respectivamente, apenas durante a sessão atual.

Para obter persistência entre logouts e reinicializações, você precisará editar o arquivo /etc/selinux/config e definir a variável SELINUX como aplicando, permissiva ou desativado:

getenforce
setenforce 0
getenforce
setenforce 1
getenforce
cat /etc/selinux/config

Normalmente você usará setenforce para alternar entre os modos SELinux (aplicando para permissivo e vice-versa) como uma primeira etapa de solução de problemas. Se o SELinux estiver atualmente definido como aplicativo enquanto você estiver enfrentando um determinado problema, e o mesmo desaparecer quando você o definir como permissivo, você pode ter certeza de que está procurando em um problema de permissões do SELinux.

Contextos SELinux

Um contexto SELinux consiste em um ambiente de controle de acesso onde as decisões são tomadas com base no usuário, função e tipo do SELinux (e opcionalmente em um nível):

  1. Um usuário SELinux complementa uma conta de usuário normal do Linux mapeando-a para uma conta de usuário SELinux, que por sua vez é usada no contexto SELinux para processos naquela sessão, a fim de definir explicitamente suas funções e níveis permitidos.
  2. O conceito de função atua como intermediário entre os domínios e os usuários do SELinux, pois define quais domínios de processo e tipos de arquivos podem ser acessados. Isso protegerá seu sistema contra vulnerabilidade a ataques de escalonamento de privilégios.
  3. Um tipo define um tipo de arquivo SELinux ou um domínio de processo SELinux. Em circunstâncias normais, os processos são impedidos de acessar arquivos que outros processos usam, e de acessar outros processos, portanto o acesso só é permitido se existir uma regra de política específica do SELinux que o permita.

Vamos ver como tudo isso funciona através dos exemplos a seguir.

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

Em Protegendo o SSH – Parte 8, explicamos que alterar a porta padrão onde o sshd escuta é uma das primeiras medidas de segurança para proteger seu servidor contra ataques externos. Vamos editar o arquivo /etc/ssh/sshd_config e definir a porta para 9999:

Port 9999

Salve as alterações e reinicie o sshd:

systemctl restart sshd
systemctl status sshd

Como você pode ver, o sshd falhou ao iniciar. Mas o que houve?

Uma rápida inspeção de /var/log/audit/audit.log indica que o sshd teve permissão negada para iniciar na porta 9999 (as mensagens de log do SELinux incluem a palavra “ >AVC” para que possam ser facilmente identificados em outras mensagens) porque essa é uma porta reservada para o serviço JBoss Management:

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

Neste ponto você pode desabilitar o SELinux (mas não faça isso!) conforme explicado anteriormente e tentar iniciar o sshd novamente, e deve funcionar. No entanto, o utilitário semanage pode nos dizer o que precisamos mudar para que possamos iniciar o sshd em qualquer porta que escolhermos sem problemas.

Correr,

semanage port -l | grep ssh

para obter uma lista das portas onde o SELinux permite que o sshd escute.

Então, vamos alterar a porta em /etc/ssh/sshd_config para a porta 9998, adicionar a porta ao contexto ssh_port_t e então reiniciar o serviço :

semanage port -a -t ssh_port_t -p tcp 9998
systemctl restart sshd
systemctl is-active sshd

Como você pode ver, desta vez o serviço foi iniciado com sucesso. Este exemplo ilustra o fato de que o SELinux controla o número da porta TCP para suas próprias definições internas de tipo de porta.

EXEMPLO 2: Permitindo que o httpd envie acesso ao sendmail

Este é um exemplo de SELinux gerenciando um processo acessando outro processo. Se você fosse implementar mod_security e mod_evasive junto com o Apache em seu servidor RHEL 7, você precisa permitir que httpd acesse o sendmail para enviar uma notificação por email após um ataque (D)DoS. No comando a seguir, omita o sinalizador -P se não quiser que a alteração seja persistente durante as reinicializações.

semanage boolean -1 | grep httpd_can_sendmail
setsebool -P httpd_can_sendmail 1
semanage boolean -1 | grep httpd_can_sendmail

Como você pode ver no exemplo acima, as configurações booleanas do SELinux (ou apenas booleanas) são regras verdadeiras/falsas incorporadas nas políticas do SELinux. Você pode listar todos os booleanos com semanage boolean -l e, alternativamente, canalizá-los para grep para filtrar a saída.

EXEMPLO 3: Servindo um site estático a partir de um diretório diferente do padrão

Suponha que você esteja servindo um site estático usando um diretório diferente do diretório padrão (/var/www/html), digamos /websites (este pode ser o caso se você' Você está armazenando seus arquivos da web em uma unidade de rede compartilhada, por exemplo, e precisa montá-lo em /websites).

a). Crie um arquivo index.html dentro de /websites com o seguinte conteúdo:

<html>
<h2>SELinux test</h2>
</html>

Se você fizer,

ls -lZ /websites/index.html

você verá que o arquivo index.html foi rotulado com o tipo default_t SELinux, que o Apache não pode acessar:

b). Altere a diretiva DocumentRoot em /etc/httpd/conf/httpd.conf para /websites e não se esqueça de atualizar o bloco de diretório correspondente. Em seguida, reinicie o Apache.

c). Navegue até http:// e você deverá obter uma resposta HTTP 503 Forbidden.

d). Em seguida, altere o rótulo de /websites, recursivamente, para o tipo httpd_sys_content_t para conceder ao Apache acesso somente leitura a esse diretório e seu conteúdo:

semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"

e). Por fim, aplique a política SELinux criada em d):

restorecon -R -v /websites

Agora reinicie o Apache e navegue até http:// novamente e você verá o arquivo html exibido corretamente:

Resumo

Neste artigo, abordamos os fundamentos do SELinux. Observe que devido à vastidão do assunto, uma explicação completa e detalhada não é possível em um único artigo, mas acreditamos que os princípios descritos neste guia o ajudarão a avançar para tópicos mais avançados, caso deseje.

Se me permitem, deixe-me recomendar dois recursos essenciais para começar: a página NSA SELinux e o guia do usuário e administrador do RHEL 7 SELinux.

Não hesite em nos informar se tiver alguma dúvida ou comentário.