Containers Linux por dentro: namespaces, cgroups e seccomp

O que são containers Linux em poucas linhas

Containers Linux não são máquinas virtuais completas. Eles usam recursos do kernel para isolar processos, arquivos, rede e limites de recursos dentro do mesmo sistema operacional.

O artigo Linux containers in 500 lines of code mostra uma implementação didática que acabou passando de 500 linhas após revisões. O objetivo é entender as peças, não substituir Docker ou uma plataforma de produção.

A ideia é valiosa para desenvolvedores porque revela o que existe por baixo de uma ferramenta de containers: namespaces, capabilities, cgroups, setrlimit, mounts e seccomp.

Como funciona

Namespaces controlam a visão que um processo tem do sistema. Um namespace de PID pode esconder processos do host, enquanto namespaces de rede, montagem, IPC e hostname criam visões separadas.

Capabilities dividem privilégios normalmente associados ao usuário root. Cgroups limitam memória, CPU, processos e I/O. setrlimit complementa esses limites com controles mais antigos.

O programa didático cria um processo com clone, prepara recursos, troca a raiz com pivot_root, aplica restrições e executa o comando escolhido. Cada etapa depende de permissões e da versão do kernel.

Principais recursos

A implementação usa isolamento de montagem, PID, IPC, rede e hostname. Também prepara uma árvore de processos separada e limpa montagens antigas.

Ela reduz capabilities, aplica filtros de chamadas de sistema com seccomp e configura limites de recursos com cgroups e setrlimit.

O diferencial é a transparência. Em vez de esconder a complexidade atrás de uma CLI, o exemplo permite relacionar cada mecanismo a uma parte pequena do código.

Como começar: instalação e acesso

Use uma máquina Linux de laboratório, com compilador C e as bibliotecas necessárias para capabilities e seccomp. O artigo não recomenda essa abordagem mínima para qualquer serviço exposto.

Leia o código e o artigo antes de executar. O exemplo depende de privilégios, diretórios de filesystem e características do kernel que variam entre distribuições.

gcc -Wall -Werror -lcap -lseccomp contained.c -o contained

Faça testes somente em ambiente descartável e com arquivos autorizados. A intenção é aprendizado de isolamento, não executar código desconhecido no computador pessoal.

Exemplo prático

O exemplo original executa um shell usando uma imagem de filesystem indicada por linha de comando. O processo recebe uma nova visão de recursos e limites antes de iniciar.

Durante a execução, a ferramenta configura cgroups para memória, CPU, processos, I/O e outros limites. Depois remonta a raiz, tenta usar user namespace e aplica restrições.

sudo ./contained -m /caminho/imagem -u 0 -c /bin/sh

Esse comando é apenas uma referência didática. Não use uma imagem ou programa não confiável sem isolamento adicional e sem compreender as permissões envolvidas.

Comparação com alternativas

Docker e Podman oferecem imagens, redes, volumes, logs e uma experiência operacional pronta. São opções mais adequadas para desenvolvimento cotidiano e automação.

Uma máquina virtual fornece isolamento mais forte por usar outro kernel, mas normalmente consome mais recursos e exige uma camada de virtualização.

O código didático é melhor para estudar fundamentos. Ele não possui o ecossistema, as políticas e as verificações que uma plataforma madura precisa para produção.

Pontos positivos e limitações

O maior benefício é entender o mecanismo real sem depender de uma abstração. O artigo também relaciona cada restrição a riscos de privilégios e chamadas do kernel.

A limitação é segurança operacional. User namespaces, capabilities e seccomp têm detalhes difíceis, e vulnerabilidades de kernel podem alterar o nível de isolamento.

Além disso, o exemplo é sensível ao kernel, às bibliotecas e ao filesystem. A implementação deve ser tratada como material educacional, não como sandbox pronta.

Casos de uso reais

Estudantes podem usar o projeto para aprender chamadas de sistema, processos e isolamento no Linux.

Profissionais de segurança podem comparar os mecanismos básicos com as garantias de runtimes modernos durante uma revisão arquitetural.

Desenvolvedores de ferramentas de infraestrutura podem usar a leitura para entender por que um runtime precisa configurar várias camadas ao iniciar um container.

Dicas e boas práticas

Documente kernel, arquitetura, permissões e filesystem em cada experimento. Reprodutibilidade é parte do aprendizado de infraestrutura.

Vale a pena?

Vale para quem quer entender containers desde o kernel e conectar conceitos de Linux a ferramentas modernas.

Não vale como substituto de Docker, Podman, uma VM ou um sandbox dedicado. O exemplo não oferece as garantias operacionais de uma solução mantida para produção.

O próximo passo é ler o artigo original, compilar em uma máquina de laboratório e comparar cada mecanismo com a documentação oficial do Linux.