Verifique as labels antes de culpar o SELinux

Quando uma aplicação deixa de funcionar num host com SELinux em enforcing, o reflexo em muitas equipas é passar o SELinux para permissive e seguir em frente. Nós mantemo-lo em enforcing em todos os hosts que operamos, e na nossa experiência a causa é normalmente muito mais pequena do que o reflexo sugere: um ficheiro com a label errada. Este artigo mostra como encontrar isso depressa, corrigi-lo da forma certa e evitar ficar trancado do lado de fora enquanto o faz.

O que é uma label, e como corre mal

O SELinux toma decisões com base em labels. Cada ficheiro e cada processo transporta um contexto de segurança, e a política diz que tipos de processo podem fazer o quê a que tipos de ficheiro. A política diz também que label cada caminho deve ter: o conteúdo de /var/www deve ser httpd_sys_content_t, um executável em /usr/bin deve ser bin_t, e assim por diante. Essas labels esperadas são as regras de file context.

Um ficheiro recebe a sua label quando é criado, normalmente herdada do diretório pai ou definida por uma regra da política. Isso funciona bem até os ficheiros chegarem por um caminho invulgar:

• O mv mantém a label original, por isso um ficheiro criado num diretório pessoal e movido para uma web root continua a dizer que pertence a um diretório pessoal.
• Arquivos descompactados sem atributos SELinux, ou repostos de um backup que não os guardou, recebem o que o diretório de destino lhes der.
• Conteúdo colocado numa localização personalizada, como /srv/app, recebe uma label genérica porque a política ainda não tem regra para esse caminho.

Em todos esses casos a política está bem. O ficheiro está simplesmente a usar a label errada, e o processo que precisa dele é recusado.

Leia primeiro a negação

Antes de alterar seja o que for, leia o que o SELinux recusou de facto:

ausearch -m AVC -ts recent

Cada negação nomeia o tipo de processo (scontext), o tipo de destino (tcontext), a classe de objeto e a permissão. Se o tipo de destino parecer errado para aquele ficheiro (um servidor web impedido de ler algo etiquetado user_home_t, por exemplo), está quase de certeza perante um problema de labels, não uma falha de política.

Compare o que existe com o que devia existir

Três comandos respondem diretamente à pergunta:

ls -Z /path/to/file            # the label it has
matchpathcon /path/to/file     # the label the policy expects
restorecon -nv /path/to/file   # dry run: what restorecon would change

O restorecon -n não altera nada. Apenas reporta a diferença entre a label atual e a esperada, o que faz dele a ferramenta de auditoria perfeita. Corra-o sobre uma árvore inteira depois de uma instalação, de um restore ou de uma migração:

restorecon -Rnv /etc /usr /var /srv 2>/dev/null

Um resultado vazio significa que todos os ficheiros sob esses caminhos têm a label que a política espera. Qualquer linha na saída é um ficheiro que não a tem, e essa lista costuma ser curta e muito reveladora. Corremos este tipo de verificação em construções novas por rotina, e os nossos modelos de instalação voltam a etiquetar os caminhos críticos no passo de pós-instalação, para que um host novo comece a vida com as labels corretas antes de alguém iniciar sessão.

Corrija da forma certa

Para um ficheiro que simplesmente tem a label errada, volte a etiquetá-lo com o que a política espera:

restorecon -Rv /path

Para uma localização personalizada que a política não conhece, ensine primeiro a regra à política e só depois volte a etiquetar, para que a correção sobreviva ao próximo relabel completo:

semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?"
restorecon -Rv /srv/app

O chcon também altera labels, mas só até ao próximo relabel, depois do qual o problema volta. Use-o para experiências, não para correções.

Se as labels estão certas e a negação diz respeito a comportamento, verifique os booleans antes de escrever política. Muitas necessidades comuns, como um servidor web a abrir ligações de rede de saída, são um único interruptor:

getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Desconfie do audit2allow

O audit2allow lê negações e escreve um módulo de política que as permite. Produz sempre algo que funciona, e é exatamente esse o perigo. Se a verdadeira causa for um ficheiro mal etiquetado, o módulo gerado concede uma permissão ampla para fazer desaparecer o sintoma, e todos os outros ficheiros e processos desse tipo herdam a política mais fraca. Leia o que ele propõe. Uma regra que permite a um domínio transitar para outro muito privilegiado, ou ler tudo o que tem um tipo comum, é um forte indício de que a label está errada e de que o módulo é a correção errada. Os módulos personalizados são por vezes corretos, para software interno sem política própria, mas devem ser o último passo, não o primeiro.

Passar a enforcing em segurança num host remoto

Passar uma máquina remota de permissive para enforcing é uma daquelas alterações que podem cortar a sua própria sessão se alguma coisa ainda estiver mal etiquetada. Arme primeiro uma rede de segurança, para que o host se reponha sozinho se perder o acesso:

systemd-run --on-active=240 --unit=selinux-net /usr/sbin/setenforce 0
setenforce 1
# open a NEW ssh session and confirm it works
systemctl stop selinux-net.timer

O systemd dispara o timer quer a sua sessão sobreviva quer não. Cancele-o apenas depois de um início de sessão totalmente novo ter funcionado. O mesmo padrão serve para alterações de firewall, SSH e encaminhamento numa máquina até à qual não pode ir a pé.

Uma lista de verificação curta

• Corra restorecon -Rnv sobre os caminhos do sistema depois de cada instalação, restore ou migração.
• Leia a negação AVC e compare ls -Z com matchpathcon antes de alterar a política.
• Use semanage fcontext mais restorecon para caminhos personalizados, não chcon.
• Verifique os booleans antes de escrever um módulo.
• Trate a saída do audit2allow como uma pergunta, não como uma resposta.
• Nunca passe um host remoto a enforcing sem um caminho de regresso temporizado.

Se um fornecedor de aplicações lhe disse para desativar o SELinux e preferia não o fazer, teremos todo o gosto em ajudar a encontrar a correção exata. Fale com um engenheiro

Related

Relacionados: O hardening baseline em cada host · Resposta de emergência a vulnerabilidades no mesmo dia