SELINUX – Não, não serve só para desabilitar – Comunidade AW2NET
SELINUX Básico
Não. Não serve só para desabilitar!
Muitas pessoas possuem medo deste nome, evitam ambientes com este recurso habilitado e tão pouco recomendam aos outros que o utilizem. Mas porque ?
Pelo que eu ouço dizer, muita gente acha que SELinux é complicado demais desnecessário até mesmo em ambientes corporativos. Oh God, Why?
Bom, vamos parar de enrolação, o intuíto deste artigo é o de mostrar o funcionamento básico desta ferramenta que só tem a somar em segurança em sistemas Linux.
1 – Primeiros passos: Pra que serve isso mesmo?
SELinux ou Security-Enhanced Linux é um método adicional de segurança para ambientes Linux que trabalha com políticas de segurança para todo Usuário/Processo que utiliza o sistema.
E pra que serve isso mesmo²?
O Linux por default, trabalha com controles de Acesso do tipo Discricionário (DAC), que são aquelas permissões comuns que você está acostumado a ver [espero] quando pretende utilizar algum tipo de segurança para algum arquivo:
-rw-r–r–. 1 root root 0 Apr 3 01:25 arquivo
Owner, Group e Others lembra? Pois é. Mas quando falamos de SELinux, falamos de Controle de Acesso Mandatório (MAC), que pode restringir um usuário de acessar até mesmo algo que ele próprio criou.
Adicionando "rótulos" ou "categorias" para todos os objetos de um Filesystem, os usuários e processos devem ter o acesso adequado a estas categorias ANTES de poder interagir com esses objetos.
Legal. E pra que serve isso mesmo³?
Quando alguém (ex: um processo, serviço, etc), tenta acessar um objeto (ex: um arquivo), O Selinux vai verificar em seu database (AVC) onde estão as permissões destes, e neste caso, se os dois não estiverem na mesma categoria de permissionamento, o acesso é negado. Pronto.
É feito uma espécie de grep neste procedimento e se a permissão estiver diferente, o acesso é negado.
Com o SELinux, você é capaz de garantir que nada vá sair do controle dentro de qualquer ambiente.
Mais um exemplo prático: Anime-se 😉
Presumindo que nós desejamos permitir acesso anônimo para o nosso webserver, logo devemos abrir as devidas portas no nosso firewall, etc. Entretanto, isso significa [certamente] que pessoas maliciosas podem tentar invadir este webserver e compromenter o nosso trabalho. Facilmente um cracker pode tomar posse do processo/usuário responsável pelo serviço do apache por exemplo.
Este usuário (do apache) tem permissão de leitura para o document root (/var/www/html), e também permissão de escrita em /tmp, /var/tmp e de mais outros diretorios e arquivos espalhados pelo sistema.
Neste caso, o SELinux utilizaria de alguns contextos de segurança que seriam capazes de "enjaular" o processo/usuário do apache dentro somente de seu document root, impedindo o acesso a outras áreas do sistema.
2 – Ok. Mãos a obra!! Conhecendo, Ativando, Desativando e vendo as Modalidades do SELinux.
De início, para verificar se o SELinux esta ativado em seu sistema digite o comando:
Esse comando pode te trazer 3 saídas diferentes
-> Enforcing: SELinux esta ativo e operante no sistema. Dando "toco" em todo mundo.
-> Permissive: SELinux esta ativo e INOperante no sistema. Aqui não é feito nenhum bloqueio, apenas entradas de logs do que aconteceria se ele estiver ativado e avisos de segurança.
-> Disabled: é isso aí. =)
Para ativar ou desativar o SELinux "ao vivo":
# setenforce 1 \\\ Para habilitar ::: vai para Enforcing
# setenforce 0 \\\ Para desabilitar ::: vai para Permissive
Este último método não é persistente, ou seja, no proximo reboot serão carregadas as configurações default.
Para alterar de modo persistente edite o arquivo /etc/selinux/config e altere da seguinte forma:
SELINUX=enforcing ############ ALTERE ESTA LINHA
Após modificar, salve e feche o arquivo.
É importante lembrar que: Para alternar entre os modos Permissive e Enforcing nã há problemas e tudo ocorrerá normalmente. Depois de setar a opção no arquivo, é só usar o recurso setenforce para ativar ou desativar.
Entretanto, se a máquina estiver como Disabled, é recomendável (leia-se necessário) um reboot no sistema para que todos os contextos sejam devida e corretamente carregados nele.
3 – Visualisando e trabalhando com o tal do contexto.
Bom… Assim como dito, o SELinux trabalha com contextos de segurança, que por sua vez, são personalizáveis.
Para visualisar estes contextos em um arquivo ou diretório devemos lista-los utilizando o parâmetro -Z:
Display security context so it fits on most displays. Displays
only mode, user, group, security context and file name.
Vamos focar este tutorial em testes de um webserver qualquer ok? A distro usada neste tutorial foi o RHEL6.2 mas pode ser aplicada em qualquer outra distro que tenha a mesma base também.
Dentro do meu document root eu tenho o meu arquivo index.html
<title> Demonstração SELinux </title>
<h1><center> FUNCIONOU !!! </center></h1>
Como podem ver, um arquivo simples em html que mostra a seguinte página:
Agora Vamos aos contextos.
# ll –Zd /var/www/html/
# ll –Z /var/www/html/
-rw-r–r–. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html
Nesses dois comandos, eu listei o contexto do diretório html/ e do arquivo index.html. A parte que vamos nos focar neste momento é a que esta em negrito e sublinhado.
Esta legenda destacada é o contexto de segurança deste arquivo atribuido pelo SELinux. E isso é determinado (por default) pelo seu diretório pai, ou seja, eu criei um arquivo dentro de ../html/ chamado index.html e este ja recebeu automaticamente o contexto httpd_sys_content_t.
Esse contexto do httpd deve ser lido mais ou menos da seguinte forma: "tipo de conteúdo do sistema httpd"
Agora vamos ver o SELinux funcionando ( ou não =S )
Quando usamos comandos como mv ou cp -a os atributos dos arquivos são mantidos certo? E os contextos do SELinux também são mantidos nesse caso. Vejamos o exemplo:
Vou copiar o arquivo index.html do meu document root para o diretorio /tmp:
# cp /var/www/html/index.html /tmp/
O seu contexto foi alterado segundo o seu novo diretorio pai. Isso para que ele pudesse funcionar corretamente sem maiores problemas
# ll -Z /tmp/index.html
-rw-r–r–. root root unconfined_u:object_r:user_tmp_t:s0 /tmp/index.html
Legal. Agora eu vou mover esse index.html de volta para o meu document root. SÓ QUE desta vez utilizando uma linha de comando que preservará os seus atributos:
# mv /tmp/index.html /var/www/html/
mv: overwrite `/var/www/html/index.html'? Y
Listando o contexto deste arquivo de volta ao seu diretorio, podemos ver que o contexto atribuido anteriormente foi mantido:
# ll -Z /var/www/html/
-rw-r–r–. root root unconfined_u:object_r:user_tmp_t:s0 index.html
-> Reinicie o serviço do apache: # service httpd restart
-> Abra novamente a pagina do webserver e observe a saída :
Ora ora, mas vejam só. PANIC no cerebro do sysadmin agora. Mas o arquivo esta lá certinho, o serviço esta rodando, sem firewall etc… O que houve??!!
Aconteceu que o SELinux viu que o contexto do arquivo index.html não é do "tipo de conteúdo do sistema httpd".
E como ele sabia que era esse? Olhando o contexto do seu diretório pai, que permanece da forma correta.
# ll -Zd /var/www/html/
Existem 2 formas corretas de se alterar o contexto de um determinado arquivo.
A primeira delas consiste em restaurar o contexto que deveria ser o correto para ele no diretório onde ele estiver, ou seja, o SELinux vai verificar em seu database (AVC) os contextos padrões e depois verificar qual contexto se atribui a este arquivo de acordo com o seu diretorio pai.
No nosso caso o direório pai é o ../html/
Veja a seguinte linha de comando:
# restorecon -RFvv /var/www/html
A ferramenta restorecon esta dentro do pacote policycoreutil, caso voce não tenha este comando em sua máquina.
Esse comando vai restaurar de um modo Recursivo (R), Forçado (F) e em modo verbose (vv) o contexto de TODOS os arquivos a partir do diretorio ../html/ e vai gerar a seguinte saída para nós neste caso:
restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:httpd_sys_content_t:s0
Observe que o contexto do arquivo index.html foi restaurado. Logo, se você reiniciar o serviço do apache agora e testar o acesso, este será possivel sem problema algum.
Curiosidade: O recurso restorecon é executado na raiz do sistema toda vez que a máquina é ligada e esta em modo Permissive ou Enforcing. Quando um host esta com o SELinux em modo Disabled esse processo não é executado no boot, por isso é necessário o reboot do sistema quando o SELinux é ativo nele.
A segunda maneira, que é também a mais utilizada, consiste em literalmente alterar manualmente (ou quase isso) o contexto de um arquivo utilizando a ferramenta semanage .
A ferramenta semanage esta dentro do pacote policycoreutil-python, caso voce não tenha este comando em sua máquina.
Tendo o cenário atual (e funcionando por enquanto :p ):
-rw-r–r–. root root system_u:object_r:httpd_sys_content_t:s0 index.html
Vamos alterar este contexto para um outro qualquer.
Um recurso legal que pode ser utilizado no semanage é o seguinte:
Vai listar todos os contextos de todos os arquivos que estão armazenados no AVC. É uma boa base pra quando você não lembrar o nome de algum contexto que deseja usar. Por exemplo:
# semanage fcontext -l | grep http | grep /www
/usr/share/awstats/wwwroot(/.*)? all files system_u:object_r:httpd_awstats_content_t:s0
/usr/share/awstats/wwwroot/cgi-bin(/.*)? all files system_u:object_r:httpd_awstats_script_exec_t:s0
Ok. Tendo escolhido um contexto (no meu caso foi o user_tmp_t) para o nosso arquivo, vamos altera-lo utilizando o seguinte comando:
# semanage fcontext -a -t user_tmp_t '/var/www/html(/.*)?'
Esse comando vai adicionar user_tmp_t como o contexto dos arquivos que estiverem dentro do diretorio ./html/, que no caso é o index.html
O que? Aquele monte de pontos ali ? <…(/.*)?'>Não esta errado não. Isso o SELinux usa pra saber onde esta sendo aplicado o contexto que você quer, então sim, você tem que usar sempre! 🙂
# ll -Z /var/www/html/index.html
-rw-r–r–. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
Note que mesmo depois de executar o comando, o contexto ainda não foi alterado pois o intuito do comando é o de adicionar o contexto ao arquivo no database (AVC), ou seja, de maneira persistente e não troca-lo na mesma hora.
Após utilizar o restorecon, será possivel visualisar o contexto escolhido:
# restorecon /var/www/html/index.html
-rw-r–r–. root root system_u:object_r:user_tmp_t:s0 /var/www/html/index.html
Agora, ao reiniciar o serviço do apache novamente, a pagina estará indisponível. 🙂
Uso: É importante e necessário que conheçamos esse recursos quando formos trabalhar em ambientes muito customizados. Quer um exemplo bacana?
Suponha que um cliente esta com problemas em seu webserver e use o SELinux, e você percebe que o document root dele é o /website ao invés de /var/www/. Logo, ao notar isso, qual é a primeira coisa a se fazer?
Se, "conferir todos os contextos para ver se estão corretos" foi a sua resposta, te dou um meio certo. 🙂
Dica: se tem SELinux e deu problema, o primeiro comando tem que ser setenforce 0, esse é o troubleshooting básico. Assim você identifica se o problema é o SELinux ou o serviço. Não adianta olhar 1000 contextos sendo que o virtual host desse ambiente esta configurado de maneira errada.
Agora… Se desabilitando o SELinux o serviço funcionar! Vá verificar os contextos utilizando os comandos que foram passados neste artigo! 😉
Obviamente, se fossemos comentar sobre todos os Recursos do SELinux aqui, daria para escrever um livro. A minha idéia é de segmentar esse assunto e tentar ser o mais didático possivel.
Nos próximos posts, veremos como trabalhar com "boleanos" no SELinux e tecnicas básicas de troubleshooting, exemplificando tudo com outros serviços também (ftp, nfs, etc).
Espero que este artigo seja útil para você .
[important]Todos os procedimentos podem ser consultados na documentação oficial de RedHat no portal[/important]
[notice]Obs.; Este Artigo foi escrito por Vitor Zanoni e somente estamos recuperando, por isso está em meu nome.[/notice]