Do LSM ao netfilter na OCI: desmistificando selinux e liberando portas no Ubuntu minimal 24.04

Quem administra servidores Linux sabe que, muitas vezes, o que parece um problema simples de permissão ou rede esconde camadas de decisões arquiteturais do kernel e particularidades de provedores de nuvem. Recentemente, passei por duas situações práticas em ambientes Ubuntu 24.04 (Noble Numbat) (especificamente em instâncias rodando na Oracle Cloud Infrastructure (OCI)) que ilustram a importância de entender o fluxo do kernel em vez de rodar comandos no escuro.

Abaixo, detalho os dois cenários: a gestão de LSM (Linux Security Modules) desmistificando o SELinux no Ubuntu e o clássico caso da porta em TCP_LISTEN que não responde externamente.

Cenário 1: SELinux no Ubuntu: entendendo o kernel e os lsms#

No ecossistema Debian/Ubuntu, o LSM padrão sempre foi o AppArmor. O SELinux entra em cena geralmente quando é instalado explicitamente via pacotes (selinux-basics, selinux-policy-default) ou quando são utilizadas imagens cloud customizadas.

Como o SELinux opera no kernel#

O SELinux opera associando rótulos de segurança aos recursos via atributos estendidos (xattr) nos inodes do sistema de arquivos (security.selinux). Toda vez que um processo tenta executar uma syscall sensível (como open(), bind() ou execve()), o kernel aciona o hook security_compute_av. Se o sistema estiver em modo Enforcing, ele consulta o AVC (Access Vector Cache) para validar a transição de contexto.

Para desabilitar ou flexibilizar o SELinux, há três níveis de intervenção:

1. Desativação em runtime (sem reboot)#

Para interromper bloqueios imediatos sem reiniciar a máquina, altere o modo para Permissive:

sudo setenforce 0

Nesse estado, o kernel continua gerando logs de auditoria no audit log ou dmesg, mas não bloqueia nenhuma chamada de sistema:

getenforce
# Retorno esperado: Permissive

2. Configuração persistente via arquivo#

Para manter o modo permissivo ou desabilitado entre reinicializações, edite /etc/selinux/config:

# /etc/selinux/config
SELINUX=permissive
SELINUXTYPE=default

Nota técnica: Em kernels modernos (Linux 5.6+), definir SELINUX=disabled nesse arquivo apenas desliga o carregamento da política no userspace; a infraestrutura do módulo SELinux continua registrada no kernel. Para desligar o módulo completamente, a intervenção precisa ocorrer no bootloader.

3. Desativação definitiva no kernel (GRUB)#

Para remover completamente a inicialização do SELinux e garantir que o AppArmor assuma como LSM principal sem concorrência de hooks, edite /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash selinux=0 lsm=landlock,lockdown,yama,integrity,apparmor,bpf"

Atualize o GRUB e reinicie o host:

sudo update-grub
sudo reboot

Após o reboot, confirme a ordem e os módulos de segurança ativos:

cat /sys/kernel/security/lsm
# Retorno esperado: landlock,lockdown,yama,integrity,apparmor,bpf

Cenário 2: O Bloqueio de Portas no Ubuntu Minimal 24.04 (OCI)#

O segundo cenário é um clássico que confunde muitos usuários na Oracle Cloud: você sobe um serviço (como um container Docker, backend Node.js ou proxy reverso), verifica que a porta está em estado LISTEN, libera a regra no painel da VCN, mas a requisição externa morre em timeout.

1. Verificando o socket local#

O primeiro passo é garantir que o processo está ouvindo em todas as interfaces:

sudo ss -tulpn | grep 8088

• Correto: 0.0.0.0:8088 ou [::]:8088 (escutando em todas as interfaces de rede).
• Incorreto: 127.0.0.1:8088 (acessível apenas localmente dentro da VM).

2. A armadilha do iptables no Ubuntu minimal da OCI#

As imagens do Ubuntu 24.04 Minimal fornecidas pela OCI vêm com um conjunto pré-configurado de regras no iptables carregado via netfilter-persistent. No final da chain INPUT, existe uma regra que descarta qualquer pacote que não tenha sido aceito explicitamente antes:

REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

Se você simplesmente rodar sudo iptables -A INPUT -p tcp --dport 8088 -j ACCEPT, o parâmetro -A (append) insere a sua regra abaixo do REJECT. O pacote bate na regra de rejeição antes de alcançar a sua liberação.

Como inserir a regra corretamente#

Insira a regra no topo da chain utilizando -I INPUT 1:

# Inserir regra na posição 1 da chain INPUT
sudo iptables -I INPUT 1 -p tcp --dport 8088 -j ACCEPT

# Salvar imediatamente para não perder no reboot
sudo netfilter-persistent save

3. Entendendo o backend do Netfilter (iptables-nft vs legacy)#

No Ubuntu 24.04, o iptables utiliza a camada de compatibilidade do nftables por padrão (iptables-nft). Inspecione as regras ativas e os contadores de pacotes:

sudo iptables -L INPUT -n -v --line-numbers

Observe a coluna pkts. Ao disparar um teste de conexão a partir da sua máquina local:

nc -zv -w 3 <IP_PUBLICO_DA_VM> 8088

Se o contador pkts da sua regra aumentar, o pacote passou pelo firewall do Linux e chegou ao socket da aplicação. Para entender mais sobre a arquitetura de borda e Security Lists da OCI, confira também o guia sobre por que abrir portas na Oracle Cloud falha.

Conclusão: considerações práticas#

Trabalhar com instâncias em nuvem exige olhar para o sistema operacional como uma pilha integrada de segurança e rede:

1. LSMs não devem competir: Se estiver no Ubuntu, mantenha o AppArmor como LSM primário. Não instale pacotes do SELinux a menos que sua aplicação exija estritamente políticas baseadas em Type Enforcement.
2. Cuidado com a ordem das chains no Netfilter: No ecossistema OCI, sempre insira regras no topo com -I INPUT 1 e valide a persistência com netfilter-persistent save.
3. Valide a tríade de rede: Sempre teste a cadeia completa, Security Lists/NSGs na nuvem, regras de INPUT no kernel do host e o bind do socket (0.0.0.0) na aplicação.

Veja também

Infraestrutura Por que abrir portas na Oracle cloud falha: security lists vs iptables do Linux

Infraestrutura O dia em que o kernel do Rocky Linux 8 "quebrou" meu iptables (e como resolvi)

Servidores Do 'no route to host' ao virtual host: debugging de Nginx standalone e redes na nuvem

Este post está licenciado sob CC BY-NC.