O que é SELinux e como ele pode melhorar a segurança em servidores Linux?

Quando a maioria dos administradores de sistemas pensa em fortalecer um servidor Linux, concentra-se nos fundamentos: manter pacotes atualizados, configurar regras de firewall e restringir o acesso SSH. Estas são todas as medidas válidas e necessárias — mas deixam uma lacuna significativa. Um dos mecanismos de segurança mais poderosos e frequentemente subutilizados disponíveis no Linux é o SELinux (Security-Enhanced Linux), um framework de controlo de acesso obrigatório ao nível do kernel, concebido para conter ameaças antes de se transformarem em compromissos completos do sistema.

Quer esteja a executar um ambiente de VPS Hosting, uma aplicação de alto tráfego em Servidores Dedicados, ou uma plataforma de Alojamento Web Partilhado multi-inquilino, o SELinux pode ser a camada decisiva que transforma uma violação grave num incidente contido e recuperável.

O que é SELinux?

SELinux é um módulo de segurança do kernel Linux que implementa Controlo de Acesso Obrigatório (MAC). Para compreender por que isto é importante, primeiro precisa compreender o que substitui — ou melhor, o que aumenta.

O modelo de segurança tradicional do Linux baseia-se em Controlo de Acesso Discricionário (DAC). Sob DAC, as permissões de acesso são determinadas pela propriedade de ficheiros e associação a grupos. O utilizador root tem poder irrestrito sobre todo o sistema. Se um atacante obtiver root, obtém tudo.

Sob o modelo MAC do SELinux, o acesso é governado por políticas de segurança em todo o sistema que são aplicadas ao nível do kernel. Criticamente, até o utilizador root está sujeito a estas restrições. Um processo em execução como root não pode executar ações que a sua política SELinux não permita explicitamente.

O SELinux foi originalmente desenvolvido pela Agência de Segurança Nacional (NSA) em colaboração com a Red Hat e foi integrado no kernel Linux principal no início dos anos 2000. Hoje é um componente padrão de distribuições Linux de nível empresarial, incluindo RHEL, CentOS, Fedora, AlmaLinux e Rocky Linux.

Onde a Segurança Tradicional do Linux Fica Aquém

O modelo de permissões UNIX clássico tem servido bem o Linux durante décadas, mas carrega fraquezas estruturais que os atacantes modernos exploram rotineiramente:

• Root é omnipotente. Qualquer exploit que escale com sucesso para root dá ao atacante acesso irrestrito a todo o sistema — ficheiros, bases de dados, sockets de rede e tudo.
• Compromisso de serviço equivale a compromisso de sistema. Um módulo Apache vulnerável, um script PHP mal codificado ou uma aplicação mal configurada podem ser usados para pivotar em todo o servidor.
• Vectores de ataque modernos contornam DAC completamente. Web shells, exploits de escalação de privilégios, escapes de contentor e ataques da cadeia de fornecimento são concebidos para operar dentro dos limites das permissões tradicionais enquanto ainda causam danos catastróficos.

Cenário de Ataque do Mundo Real

Considere uma vulnerabilidade comum de CMS que permite a um atacante fazer upload e executar uma web shell.

Sem SELinux: O atacante lê config.php, extrai credenciais de base de dados, despeja a base de dados, move-se lateralmente para outros sites alojados e potencialmente obtém acesso root completo. Toda a stack é comprometida a partir de um único ponto de entrada.

Com SELinux: O processo do servidor web Apache é executado no domínio httpd_t. A política restringe estritamente o que httpd_t pode aceder. A web shell não pode ler ficheiros fora do domínio de conteúdo designado, não pode abrir ligações de rede não autorizadas e não pode tocar em ficheiros de configuração do sistema. A violação é contida na camada de aplicação.

Este é o valor central do SELinux: contenção de danos através do confinamento de processos.

Como Funciona o SELinux: Contextos de Segurança e Aplicação de Políticas

O SELinux funciona atribuindo um contexto de segurança (rótulo) a cada processo, ficheiro, porta e socket de rede no sistema. As políticas definem então quais contextos são permitidos interagir uns com os outros. O kernel aplica estas regras em cada tentativa de acesso.

Um Exemplo Concreto

A política SELinux permite que httpd_t leia ficheiros rotulados como httpd_sys_content_t. Não permite que httpd_t leia shadow_t.

Se Apache — seja legitimamente ou devido a exploração — tentar ler /etc/shadow, o kernel nega o pedido e escreve uma entrada de violação detalhada em /var/log/audit/audit.log. O ataque é bloqueado e documentado simultaneamente.

Modos de Operação do SELinux

O SELinux funciona em três modos distintos:

Verificar e Definir o Modo Atual

# Check current SELinux status
getenforce
sestatus

# Temporarily switch to permissive mode (no reboot required)
setenforce 0

# Switch back to enforcing mode
setenforce 1

Para alterar permanentemente o modo, edite /etc/selinux/config e defina SELINUX=enforcing (ou permissive), depois reinicie.

> Melhor Prática: Implemente novos servidores em modo Permissive primeiro. Revise os registos de auditoria, identifique quaisquer processos legítimos que estejam a ser sinalizados, ajuste as suas políticas e depois mude para Enforcing para produção. Esta abordagem evita interrupções operacionais enquanto garante que as suas políticas são precisas.

Tipos de Política do SELinux

O SELinux é fornecido com vários tipos de política adequados a diferentes ambientes:

Política Direcionada (Padrão e Recomendada)

Aplica restrições MAC apenas a serviços virados para a rede, como Apache, Nginx, Postfix, Dovecot e DNS. Todos os outros processos são executados num domínio não confinado. Este é o melhor equilíbrio entre segurança e usabilidade para a grande maioria de cargas de trabalho de VPS e servidores dedicados.

Política Rigorosa

Aplica MAC a todos os processos no sistema, incluindo sessões de utilizador. Fornece segurança máxima mas requer significativamente mais gestão de políticas e conhecimento operacional.

MLS/MCS (Segurança Multi-Nível / Segurança Multi-Categoria)

Tipos de política avançados concebidos para ambientes de nível governamental, classificados ou altamente regulados, onde os dados devem ser isolados em múltiplos níveis de sensibilidade simultaneamente.

Para a maioria das implementações de servidores de produção, a Política Direcionada é a escolha correta.

Por Que o SELinux É Importante para Alojamento, DevOps e Conformidade

O SELinux oferece benefícios de segurança tangíveis numa ampla gama de contextos operacionais:

Isolamento de Processos

Cada serviço confinado funciona dentro do seu próprio domínio de segurança. Comprometer um serviço — digamos, uma aplicação web — não concede acesso a outros serviços em execução no mesmo host. Isto é especialmente valioso em ambientes de servidor multi-aplicação.

Aplicação do Princípio do Menor Privilégio

O SELinux aplica o princípio do menor privilégio ao nível do kernel. Os processos só podem aceder aos recursos que explicitamente precisam. Mesmo que um atacante obtenha root dentro de um processo confinado, não pode exceder as permissões definidas pela política.

Registos de Auditoria e Perícia

Cada tentativa de acesso negada é registada em /var/log/audit/audit.log com contexto completo: o processo envolvido, o recurso que tentou aceder, os contextos de segurança de ambos e um carimbo de data/hora. Isto torna a perícia pós-incidente dramaticamente mais eficaz.

Segurança de Contentores

O SELinux impede que contentores Docker e Podman escapem dos seus limites e acedam aos recursos do host. Esta é uma camada de defesa crítica para cargas de trabalho containerizadas onde as vulnerabilidades de escape de contentor são uma classe de ataque conhecida.

Conformidade Regulatória

O SELinux é um controlo obrigatório em vários frameworks de conformidade, incluindo PCI DSS, HIPAA e normas de segurança militares/governamentais. Executar o SELinux em modo Enforcing com uma política documentada é frequentemente um pré-requisito para passar auditorias de segurança em indústrias reguladas.

Comandos SELinux Essenciais para Administradores de Sistemas

Aqui estão os comandos mais comumente usados para gerir o SELinux em operações diárias:

Verificar o Estado do SELinux

getenforce
sestatus

Restaurar Contextos de Ficheiros Após Mover Ficheiros Web

Quando ficheiros são movidos em vez de copiados, podem reter rótulos de segurança incorretos. Use restorecon para corrigir isto:

restorecon -Rv /var/www/html

Listar Rótulos de Segurança de Ficheiros

ls -Z /var/www/html

Permitir Ligações de Saída do Serviço Web (por exemplo, para chamadas de API ou proxying)

setsebool -P httpd_can_network_connect 1

Permitir que Apache se Conecte a uma Base de Dados

setsebool -P httpd_can_network_connect_db 1

Rever Ações Negadas Recentes no Registo de Auditoria

ausearch -m avc -ts recent

Gerar um Módulo de Política Personalizado a partir de Negações de Auditoria

audit2allow -a -M my_custom_policy
semodule -i my_custom_policy.pp

> Importante: Investigue sempre negações de auditoria antes de criar regras de permissão. audit2allow é uma ferramenta poderosa, mas permitir cegamente todas as negações derrota o propósito do SELinux. Compreenda o que cada regra permite antes de a aplicar.

Armadilhas Comuns do SELinux e Como Evitá-las

Desabilitar o SELinux em vez de corrigi-lo. O erro mais comum que os administradores cometem é desabilitar permanentemente o SELinux quando encontram uma negação. Isto remove uma camada inteira de proteção. Em vez disso, use audit2allow e setsebool para resolver problemas específicos enquanto mantém o SELinux ativo.

Rótulos de ficheiros incorretos após implementações manuais. Se implementar ficheiros de aplicação copiando-os de um local não padrão, podem herdar rótulos incorretos. Sempre execute restorecon após operações de ficheiros manuais em raízes web e diretórios de aplicação.

Não rever registos em modo Permissive. Saltar a fase Permissive e ir diretamente para Enforcing num servidor de produção é uma receita para interrupções inesperadas. Sempre valide políticas contra tráfego real antes de as aplicar.

SELinux e AlexHost: Segurança Pronta para Produção desde o Início

Os servidores AlexHost que executam distribuições Linux empresariais (AlmaLinux, Rocky Linux, CentOS) vêm com SELinux disponível fora da caixa. Quer esteja a implementar uma stack de aplicação web, um servidor de base de dados ou um ambiente de microserviços containerizado, o SELinux fornece a camada de controlo de acesso fundamental que mantém as suas cargas de trabalho resilientes contra exploração.

Se estiver a gerir o seu servidor através de um painel de controlo, os ambientes de VPS com cPanel são totalmente compatíveis com SELinux em modo Direcionado, e o próprio cPanel vem com configurações conscientes de SELinux para os seus serviços geridos.

Para equipas que precisam de controlo completo sobre a sua postura de segurança — incluindo módulos de política SELinux personalizados, configurações MLS ou endurecimento orientado por conformidade — Servidores Dedicados fornecem o isolamento e acesso ao nível root necessários para implementar e manter políticas MAC de nível empresarial sem as restrições de infraestrutura partilhada.

Conclusão

O SELinux não é meramente um complemento de segurança opcional — é um componente arquitetónico fundamental que redefine como o Linux aplica controlo de acesso ao nível do kernel. Ao confinar processos a domínios de segurança bem definidos, aplicar políticas de menor privilégio que até root não pode contornar e gerar registos de auditoria detalhados de cada tentativa de acesso negada, o SELinux transforma um servidor Linux padrão num sistema significativamente mais resiliente e defensável.

Sim, o SELinux requer investimento: compreender contextos de segurança, escrever ou ajustar políticas e comprometer-se com um fluxo de trabalho que trata negações como informação em vez de obstáculos. Mas para qualquer servidor que lida com dados sensíveis, executa serviços virados para o público ou