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 mecanismos de controle de acesso de primeiro nível, eles têm algumas limitações que são abordadas pelo Security Enhanced Linux (também conhecido como SELinux de forma abreviada).
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 ao sistema inteiro.
Com essas limitações em mente, a Agência de Segurança Nacional dos Estados Unidos (NSA) primeiro desenvolveu o SELinux, um método de controle de acesso obrigatório flexível, para restringir a capacidade de processos de acessar ou realizar outras operações em objetos do sistema (como arquivos, diretórios, portas de rede, etc) para o modelo de permissão mínima, 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 está incorporado no próprio kernel e é ativado por padrão no modo Enforcing. Neste artigo, explicaremos brevemente os conceitos básicos associados ao SELinux e seu funcionamento.
Modos do SELinux
O SELinux pode operar de três maneiras diferentes:
- Enforcing: O SELinux nega o acesso com base nas regras de política do SELinux, um conjunto de diretrizes que controlam o mecanismo de segurança.
- Permissive: O SELinux não nega o acesso, mas as negações são registradas para ações que teriam sido negadas se estivessem em modo enforcing.
- Disabled (autoexplicativo).
O comando getenforce exibe o modo atual do SELinux, enquanto o comando setenforce (seguido por um 1 ou um 0) é usado para alterar o modo para Enforcing ou Permissive, 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 para enforcing, permissive ou disabled:
# getenforce # setenforce 0 # getenforce # setenforce 1 # getenforce # cat /etc/selinux/config
Geralmente, você usará o setenforce para alternar entre os modos do SELinux (de enforcing para permissive e vice-versa) como primeiro passo de solução de problemas. Se o SELinux estiver atualmente definido como enforcing enquanto você estiver enfrentando um determinado problema, e o problema desaparecer quando você o define como permissive, você pode ter certeza de que está lidando com um problema de permissões do SELinux.
Contextos do SELinux
A SELinux context consists of an access control environment where decisions are made based on SELinux user, role, and type (and optionally a level):
- A SELinux user complements a regular Linux user account by mapping it to a SELinux user account, which in turn is used in the SELinux context for processes in that session, in order to explicitly define their allowed roles and levels.
- O conceito de papel atua como intermediário entre domínios e usuários do SELinux, definindo quais domínios de processos e tipos de arquivos podem ser acessados. Isso protegerá seu sistema contra vulnerabilidades a ataques de escalonamento de privilégios.
- A type defines an SELinux file type or an SELinux process domain. Under normal circumstances, processes are prevented from accessing files that other processes use, and and from accessing other processes, thus access is only allowed if a specific SELinux policy rule exists that allows it.
Vamos ver como tudo isso funciona através dos exemplos a seguir.
EXEMPLO 1: Alterando a porta padrão para o daemon sshd
No Securing SSH – Parte 8, explicamos que alterar a porta padrão em que 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 como 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 aconteceu?
A quick inspection of /var/log/audit/audit.log indicates that sshd has been denied permissions to start on port 9999 (SELinux log messages include the word “AVC” so that they might be easily identified from other messages) because that is a reserved port for the JBoss Management service:
# cat /var/log/audit/audit.log | grep AVC | tail -1
Neste ponto, você poderia desabilitar o SELinux (mas não faça isso!) como explicado anteriormente e tentar iniciar o sshd novamente, e deveria funcionar. No entanto, o utilitário semanage pode nos dizer o que precisamos alterar para conseguir iniciar o sshd na porta que escolhemos sem problemas.
Execute,
# semanage port -l | grep ssh
para obter uma lista das portas em que o SELinux permite que o sshd escute.
Então vamos alterar a porta no arquivo /etc/ssh/sshd_config para Porta 9998, adicionar a porta ao contexto ssh_port_t e em seguida 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, o serviço foi iniciado com sucesso desta vez. 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: Permitir que httpd envie acesso sendmail
Este é um exemplo de gerenciamento do SELinux de um processo acessando outro processo. Se você pretende implementar mod_security e mod_evasive juntamente com o Apache no seu servidor RHEL 7, você precisa permitir que httpd acesse sendmail para enviar uma notificação por e-mail após um ataque (D)DoS. No comando a seguir, omita a sinalização -P se não quiser que a alteração seja persistente após 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 de boolean SELinux (ou apenas booleans) são regras verdadeiro/falso incorporadas nas políticas do SELinux. Você pode listar todos os booleans com semanage boolean -l, e alternativamente redirecionar a saída para o grep para filtrar o resultado.
EXEMPLO 3: Servir um site estático de um diretório diferente do padrão
Suponha que você esteja servindo um site estático usando um diretório diferente do padrão (/var/www/html), digamos /websites (isso poderia ser o caso se você estiver armazenando seus arquivos da web em uma unidade de rede compartilhada, por exemplo, e precisar montá-la em /websites).
a). Create an index.html file inside /websites with the following contents:
<html> <h2>SELinux test</h2> </html>
Se você fizer isso,
# 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). Change the DocumentRoot directive in /etc/httpd/conf/httpd.conf to /websites and don’t forget to update the corresponding Directory block. Then, restart Apache.
c). Browse to http://<web server IP address>, and you should get a 503 Forbidden HTTP response.
d). Next, change the label of /websites, recursively, to the httpd_sys_content_t type in order to grant Apache read-only access to that directory and its contents:
# semanage fcontext -a -t httpd_sys_content_t "/websites(/.*)?"
e). Finally, apply the SELinux policy created in d):
# restorecon -R -v /websites
Agora reinicie o Apache e acesse http://<endereço IP do servidor web> novamente e você verá o arquivo html sendo exibido corretamente:
Resumo
Neste artigo, passamos pelos conceitos básicos do SELinux. Note que, devido à extensão do assunto, uma explicação detalhada completa não é possível em um único artigo, mas acreditamos que os princípios delineados neste guia irão ajudá-lo a avançar para tópicos mais avançados, caso deseje fazê-lo.
Se me permite, deixe-me recomendar dois recursos essenciais para começar: a página NSA SELinux e o guia do Usuário e Administrador SELinux do RHEL 7.
Não hesite em nos informar se tiver alguma dúvida ou comentário.
Source:
https://www.tecmint.com/selinux-essentials-and-control-filesystem-access/