Reforçando a segurança do Linux com SELinux: um guia completo e prático

Informatec Digital » Recursos » Reforçando a segurança do Linux com SELinux: um guia completo e prático

Ao configurar um servidor Linux para produção, sua configuração padrão geralmente é bastante permissiva. Ele é projetado para funcionar perfeitamente assim que instalado, não para ser uma fortaleza . É aí que o SELinux entra como um componente essencial de segurança: ele adiciona uma camada de controle que continua funcionando mesmo quando as defesas típicas (permissões de arquivos, firewall, atualizações ) falham.

O SELinux pode parecer intimidante à primeira vista, mas, uma vez compreendidos os seus princípios básicos, torna-se uma ferramenta incrivelmente poderosa para conter explorações, limitar danos e atender a padrões de segurança como CIS, PCI DSS ou outras normas de alta criticidade. Em vez de depender do comportamento normal das aplicações, o sistema força cada processo a operar dentro de limites muito específicos.

O que é SELinux e por que ele é importante no reforço da segurança do Linux?

O Security-Enhanced Linux (SELinux) é uma extensão de segurança do kernel Linux baseada no Controle de Acesso Obrigatório (MAC). Ao contrário do controle de acesso discricionário (DAC) clássico do Unix, onde o proprietário do arquivo decide quem pode acessá-lo, no SELinux as regras são ditadas por uma política central que nem mesmo os usuários root podem sobrescrever sem alterá-la explicitamente.

Este modelo garante que as decisões de acesso sejam baseadas em rótulos de segurança (contextos) e regras predefinidas , e não apenas em permissões de leitura, gravação e execução (rwx). Mesmo que um serviço tenha sido comprometido ou possua permissões excessivas, o SELinux pode impedi-lo de acessar arquivos confidenciais, acionar outros processos ou se mover pela rede além de seus limites autorizados.

O SELinux não substitui o DAC tradicional; ele o complementa. Primeiro, as permissões padrão do Unix são verificadas e, somente se o DAC permitir a operação, o SELinux intervém para validar sua política . Se o DAC já bloquear o acesso, o SELinux não intervém nem registra nada, o que ajuda a reduzir o ruído nos logs e mantém o desempenho.

Essa abordagem em camadas é especialmente perceptível em ambientes corporativos como Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise ou openSUSE Leap , onde o SELinux está integrado aos demais mecanismos de segurança do sistema e a tecnologias modernas como contêineres e máquinas virtuais.

Conceitos-chave: Políticas, contextos e domínios do SELinux

A base do SELinux são as políticas de segurança que descrevem quem pode fazer o quê, contra o quê e como . Nessa linguagem, os processos são considerados sujeitos e os recursos do sistema (arquivos, diretórios, sockets, portas, dispositivos etc.) são objetos.

Em vez de pensar nos usuários como "root" ou "www-data", o SELinux trabalha com domínios e tiposUm processo de servidor web Apache, por exemplo, é executado no domínio. httpd_t, enquanto os arquivos enviados ao cliente têm um tipo como httpd_sys_content_tA política define quais domínios podem acessar quais tipos de dados, para quais classes de objetos (arquivo, diretório, socket, porta…) e com quais permissões específicas (leitura, gravação, execução, getattr, append, etc.).

Cada objeto possui um contexto SELinux associado , um rótulo no formato:

usuario:rol:tipo:nivel

Por exemplo, um arquivo poderia ser rotulado como system_u:object_r:httpd_sys_content_t:s0Onde O campo mais importante para a administração diária geralmente é o tipo (httpd_sys_content_t), que determina a quais domínios de processo será permitido o acesso.

Na prática, o SELinux trabalha com milhares de regras. Para evitar que isso se torne incontrolável, as políticas são divididas em módulos independentes que podem ser ativados, desativados ou atualizados sem a necessidade de recompilar um bloco monolítico gigante. Isso é crucial no RHEL, SUSE e openSUSE, onde cada serviço relevante normalmente possui seu próprio módulo de política.

Modos de operação do SELinux: imposição, permissivo e desativado.

O SELinux pode operar em três modos distintos, que determinam a extensão em que suas regras são aplicadas ao sistema em tempo real :

No modo de imposição , o kernel aplica a política rigorosamente. Qualquer ação que viole as regras é bloqueada e registrada . Este é o modo recomendado para produção quando a política está bem configurada, pois é aqui que o SELinux realmente oferece proteção.

No modo permissivo , o SELinux continua avaliando a política, mas não bloqueia nada . Todas as violações são registradas como avisos. Esse modo é ideal para testes, implantação de novos aplicativos ou ajuste fino de regras, pois permite detectar o que poderia quebrar a aplicação da política sem interromper os serviços.

No modo desativado , o SELinux é completamente desativado. Nenhuma política é aplicada e nenhum registro relacionado ao SELinux é gerado. A alternância entre o modo desativado e o modo ativo (permissivo ou restritivo) requer uma reinicialização, pois o kernel precisa inicializar com o suporte ao SELinux ativado para poder marcar o sistema de arquivos.

Uma prática muito sensata em qualquer distribuição é começar com configurações permissivas , revisar e corrigir problemas de marcação e política, e só mudar para configurações restritivas quando tudo estiver estável . Deixar essa opção permanentemente desativada remove uma das camadas de proteção mais poderosas disponíveis.

Integrando o SELinux no RHEL, Fedora, SUSE e openSUSE

Distribuições como Red Hat Enterprise Linux, Fedora e derivadas habilitam o SELinux por padrão , geralmente usando uma política direcionada que restringe principalmente os serviços do sistema iniciados pelo systemd e por alguns usuários.

No RHEL, além da política pré-configurada, uma série de ferramentas são oferecidas para evitar que o administrador tenha que lidar constantemente com regras de baixo nível. O SELinux Troubleshooter se destaca, analisando eventos de negação e sugerindo alterações específicas (como ativar um booleano, corrigir um contexto ou gerar um módulo adicional).

Além disso, o SELinux se estende a contêineres (por exemplo, com o Podman) e ambientes virtualizados. Com as tags apropriadas, cada contêiner ou máquina virtual é isolado dos demais no nível do kernel, mesmo que uma vulnerabilidade no ambiente de execução ou no hipervisor seja explorada.

No ecossistema SUSE, o SUSE Linux Enterprise Server inclui o framework SELinux em seu kernel e ferramentas , mas não uma política oficial abrangente. A abordagem recomendada é criar uma política personalizada adaptada ao seu ambiente ou usar soluções como o slemicro quando você deseja um host minimalista para contêineres ou virtualização com suporte completo ao SELinux.

No openSUSE Leap, é comum utilizar políticas disponíveis em repositórios como security:/SELinux_legacy para testes, sabendo que, para um ambiente crítico, o ideal ainda é uma política revisada e ajustada especificamente para a implementação.

Modelos de política SELinux: direcionado, MLS e mínimo

O SELinux pode funcionar com diferentes modelos de política, que determinam a abrangência e a profundidade do controle. Os três mais comuns são:

A política direcionada é projetada para ambientes gerais. Ela se concentra em restringir serviços específicos (especialmente daemons de rede) e deixa outros processos em domínios mais permissivos ou até mesmo sem restrições. É a opção padrão na maioria das distribuições porque oferece um bom equilíbrio entre segurança e compatibilidade.

La Política de Segurança Multinível (MLS) Adicione o campo de nível de sensibilidade ao contexto (s0, s1, s2, categorias, etc.) e permite Classificar informações e processos em níveis.É projetado para organizações com requisitos muito rigorosos (defesa, inteligência, ambientes confidenciais) onde é importante quem pode ver ou modificar qual nível de dados.

A política mínima é uma variante reduzida, com menos regras e controles. Ela é usada em sistemas com requisitos de segurança limitados ou onde se deseja um impacto mínimo na compatibilidade , sacrificando algumas das capacidades de confinamento do SELinux.

Em implementações reais, geralmente é preferível trabalhar com políticas modulares direcionadas , ajustando módulo por módulo o que é protegido e como, em vez de tentar gerenciar um único arquivo monolítico enorme, que é muito mais difícil de manter.

Gerenciamento de contexto: visualização, alteração e restauração de tags SELinux

Uma das principais tarefas na administração do SELinux é garantir que arquivos, diretórios, processos e portas tenham o contexto correto de acordo com a política. Um contexto atribuído incorretamente pode fazer com que um serviço pare de funcionar ou deixe um recurso muito exposto.

Para inspecionar o contexto SELinux de arquivos e diretórios, muitos comandos padrão aceitam a opção. -Z. Por exemplo, com ls -Z /ruta você pode ver Usuário, função, tipo e nível de cada entrada., e com ps Zaux Você obtém o contexto dos processos ativos.

Quando uma política é instalada e o sistema de arquivos é rotulado (por exemplo, usando setfiles o fixfiles com os arquivos file_contexts), cada rota recebe um tipo padrão de acordo com a políticaSe você criar um novo arquivo em um diretório já etiquetado, ele herdará o tipo do diretório, mas se você o mover de outro local, ele manterá sua etiqueta original, o que pode causar inconsistências.

Se uma árvore de arquivos ou diretórios tiver rótulos incorretos, você pode corrigi-los com restorecon restaura os contextos aos valores definidos na política.. Com opções como -R (recursivo) e -v (Detalhado) É fácil perceber o que está mudando. É uma etapa quase obrigatória antes de mudar do modo permissivo para o modo de imposição em sistemas que já estão em fase de testes há algum tempo.

Para declarar novos padrões de rotulagem, você usa semanage fcontextCom esta ferramenta, você escreve na política o quê O tipo SELinux deve ser atribuído a caminhos específicos ou expressões regulares.e então você aplica essas alterações ao sistema de arquivos com restoreconPor exemplo, você pode rotular um novo DocumentRoot do Apache com httpd_sys_content_t para que o servidor web possa lê-lo dentro de seu domínio restrito.

Configuração básica: habilite o SELinux e escolha o modo.

O comportamento do SELinux em nível global é controlado a partir de / etc / selinux / config, onde o modo é definido (enforcing, permissive o disabled) e a política a ser utilizada (direcionada, MLS, mínima…).

Em sistemas como RHEL ou Fedora, a política direcionada geralmente vem ativado por padrão e no modo de imposiçãoNo SUSE ou openSUSE, os parâmetros do kernel no GRUB2 devem ser ajustados para carregar o SELinux em vez do AppArmor. Isso envolve a adição de opções como: security=selinux y selinux=1 para a linha de inicialização e regenere a configuração do GRUB.

Após habilitar o SELinux na inicialização e selecionar a política, é importante realizar uma marcação inicial completa do sistema de arquivos usando setfiles ou ferramentas equivalentes. Esta etapa Pode levar tempo e é melhor fazê-lo durante um período de baixa demanda.Mas essa é a base para que o sistema inicie sem surpresas no modo de força.

Em ambientes onde você está migrando do AppArmor, é fundamental. Analise os arquivos com muita atenção. file_contexts e suas variantes locaisPorque qualquer inconsistência grave pode impedir a inicialização do sistema. Faça um backup antes e trabalhe com semanage fcontext Alinhar as políticas com a realidade do sistema é praticamente obrigatório.

SELinux e CVEs: como eles ajudam a mitigar vulnerabilidades

Fornecedores como a Red Hat incluem o SELinux como um fator em sua avaliação de impacto de CVEs . Seu modelo de gravidade (Crítica, Importante, Moderada, Baixa) leva em consideração se uma vulnerabilidade pode ser mitigada ou pelo menos contida por meio de restrições SELinux bem configuradas.

Em uma vulnerabilidade crítica de execução remota de código, tipo Log4Shell (CVE-2021-44228)Um atacante poderia injetar código em um serviço acessível pela internet. Se esse serviço for executado em um domínio SELinux altamente restrito, o potencial de dano é reduzido, porque não terá permissão para ler /etc/shadowmanipular bancos de dados sensíveis ou pivotar pelo sistema fora do que é estritamente necessário para o seu funcionamento.

Em vulnerabilidades de escalonamento de privilégios como a CVE-2023-4911 (Looney Tunables) , mesmo que a exploração seja bem-sucedida em conceder a um usuário acesso com privilégios mais elevados no nível do DAC, a política ainda pode impedir ações importantes, como carregar módulos do kernel, escrever em diretórios do sistema ou abrir determinados sockets de rede . O resultado é uma limitação no que pode ser feito com esse acesso recém-adquirido.

Em casos de vulnerabilidades moderadas (por exemplo, certos problemas no Grafana) que exigem configurações incomuns ou são difíceis de explorar, o SELinux atua como uma barreira adicional, impedindo que uma falha menor se transforme em um incidente grave. Frequentemente, a política bloqueia diretamente o acesso necessário para que a exploração comprometa o sistema.

Em vulnerabilidades de baixo impacto, como bugs que causam falhas em aplicativos de usuário (por exemplo, em editores como o vim) , o SELinux geralmente não é decisivo na prevenção do problema em si, mas ainda mantém seu papel de contenção, garantindo que um processo defeituoso não saia de seu ambiente isolado (sandbox).

SELinux em ação: um exemplo real de confinamento de servidor web

Imagine um servidor web executando RHEL ou Fedora que expõe vários aplicativos e, apesar de estar protegido com patches, acaba sendo vulnerável a um exploit de execução remota em um de seus componentes. Sem o SELinux, um atacante executando código como usuário do servidor web poderia instalar backdoors, ler credenciais ou acessar outros sistemas.

Com o SELinux em modo de imposição e uma política direcionada bem configurada, o Apache, Nginx ou processos similares são executados sob o domínio. httpd_t, o que tem permissões limitadas a arquivos rotulados com tipos como httpd_sys_content_t o httpd_sys_rw_content_te acesso controlado a portas definidas, também com o contexto apropriado.

Isso significa que, embora a vulnerabilidade permita a execução de comandos, o processo comprometido Não consegue ler arquivos como /etc/shadow nem tocar nos diretórios do banco de dados rotulados com tipos específicos (por exemplo mysqld_db_t), nem abrir conexões arbitrárias com outros serviços internos se a política de rede o restringir.

Em vez de comprometer todo o sistema, a intrusão fica confinada aos limites do domínio do site . Sim, ainda será um incidente a ser investigado, mas o impacto potencial é muito menor e o invasor terá muito mais dificuldade para operar.

Booleanos, módulos e ferramentas para ajustar políticas

Além da rotulagem adequada, o trabalho diário com o SELinux geralmente gira em torno de ajustes na política base para pequenas correções, sem a necessidade de reescrevê-la completamente . É aí que entram em cena os valores booleanos e os módulos personalizados.

Os booleanos SELinux Esses são interruptores liga/desliga que alteram partes do comportamento da política já compilada. Por exemplo, um valor booleano pode permitir ou proibir que o servidor FTP grave em determinados diretórios (no caso de allow_ftpd_anon_write), ou que o servidor web inicie conexões de saída para a rede.

Com getsebool -a o semanage boolean -l Você pode listar esses interruptores e ver suas descrições. Para alterá-los permanentemente, você usa setsebool -P nombre_booleano on|offonde a opção -P garante que a alteração seja salva no disco e persista após reinicializações.É uma forma muito prática de adaptar a política "oficial" às necessidades específicas do seu servidor.

Por outro lado, o uso de módulos de política Isso permite estender ou modificar regras sem alterar a política base. Você pode visualizar os módulos ativos com semodule -lpara desativar um com semodule -d nombre ou reativá-lo com semodule -e nombreNo SUSE/openSUSE, isso é especialmente útil para ajustar com precisão quais partes do sistema você deseja que estejam sob o foco do SELinux enquanto estabiliza sua implantação.

Quando você precisa conceder permissões adicionais muito específicas, a combinação de audit2allow y semodule Isso facilita muito a vida. Com base nos registros de /var/log/audit/audit.log, O audit2allow mostra qual regra foi bloqueada e gera um módulo. que, se instalado, permite exatamente o que antes era negado.

Registros, auditoria e solução de problemas com SELinux

Cada vez que o SELinux impede uma ação que a política não autoriza, um Negação do AVC (Negação de cache de vetor de acesso) que geralmente é registrada em /var/log/audit/audit.logdesde que o serviço auditd está funcionando.

Essas entradas incluem muitas informações: o que foi tentado fazer (avc: denied { append }, write, getattretc.), que processo o solicitou (pid, comm=), sobre qual arquivo ou recurso (name=, dev=, ino=), Qual era o contexto do processo original?scontext) e qual o contexto do destino (tcontext)A princípio, parecem frases enigmáticas, mas com um pouco de prática, são ouro puro para entender o que está acontecendo.

Para evitar enlouquecer lendo o log manualmente, ferramentas como ausearch permitir filtragem por tipo de mensagem (por exemplo, -m AVC) ou por janela temporária (-ts recentE, acima de tudo, audit2allow e utilidades como sealert ajudar a traduzir esses eventos para uma linguagem quase humana. e mostrar sugestões.

Um fluxo de trabalho típico de resolução de problemas seria usar audit2allow -w -a Para ver as explicações dos avisos mais recentes, então audit2allow -a o -i fichero para inspecionar regras específicas e, finalmente, Decida se vale a pena criar um módulo que desbloqueie essa permissão. Ou, pelo contrário, se o bloco estiver em uma posição segura e for melhor não tocá-lo.

Sempre que os módulos são gerados com audit2allow -M nombre e são instalados com semodule -iVale a pena revisar essas configurações, pois a ferramenta tende a ser generosa e pode conceder mais acesso do que o estritamente necessário. O SELinux oferece muita flexibilidade para reforçar o acesso, mas o uso descuidado pode acabar criando brechas na própria política.

SELinux em uma estratégia de segurança do Linux

O SELinux não existe isoladamente: ele está integrado a uma estratégia de segurança mais ampla que inclui usuários com privilégios limitados, firewalls, proteção de SSH, mecanismos anti-força bruta e automação de configuração.

Um padrão muito comum após a instalação de um servidor é criar um usuário com privilégios sudo limitados para nunca trabalhar como root direto, ativar um firewall de rede (como ufw ou iptables/nftables) , instalar ferramentas como o Fail2ban para bloquear tentativas de acesso repetidas e configurar o SSH com boas práticas (porta não padrão, desabilitar acesso root, autenticação por chave, limites de tentativas, criptografia robusta, etc.).

Partindo dessa base, o SELinux adiciona a camada MAC: mesmo que um atacante obtenha acesso a um usuário com privilégios sudo mal configurados ou uma senha SSH incorreta, a política ainda pode restringir quais processos e arquivos esse usuário acessa . Não é infalível, mas elimina muitas das vulnerabilidades normalmente exploradas por ataques automatizados descritos em matrizes como a MITRE ATT&CK.

Com o aumento do número de servidores, a aplicação manual de todas essas medidas de segurança torna-se impraticável. É aí que entram em cena as ferramentas de automação e orquestração (Ansible, Puppet, Chef, soluções comerciais de segurança automatizada, etc.), permitindo a implementação de políticas SELinux consistentes, o ajuste de valores booleanos, a marcação de caminhos e a manutenção dos estados desejados sem a necessidade de gastar horas por máquina.

Em organizações com centenas de nós, essa automação pode ser a diferença entre ter um ambiente razoavelmente homogêneo e seguro ou uma selva de configurações inconsistentes, onde o SELinux está desativado em metade dos servidores "para não incomodar ninguém".

Em última análise, quando o SELinux é bem implementado — com modo de imposição, contextos consistentes, políticas revisadas, módulos ajustados e logs monitorados — ele se torna uma espécie de rede de segurança que impede comportamentos estranhos, contém intrusões e ajuda a demonstrar que controles de acesso robustos estão sendo aplicados para auditorias, regulamentações e melhores práticas de segurança.