Root no Container é Root no Host? Analisando Direitos de Acesso em Containers Docker/Podman
Este artigo explora as nuances dos direitos de acesso em containers Docker e Podman, investigando se o usuário root dentro de um container possui os mesmos privilégios que o root no sistema host. Analisamos cenários com bind mounts, mapeamento de UID/GID e a influência do SELinux.
MundiX News·28 de maio de 2026·10 min de leitura·👁 11 views
Containers, ao contrário de máquinas virtuais, compartilham o kernel com o sistema host. Isso levanta uma questão crucial: como os direitos Unix se relacionam entre processos dentro de um container, containers vizinhos e a máquina host? Vamos considerar um cenário com um volume do tipo bind mount, que é um diretório do host montado dentro do container, contendo um arquivo config.yml em /some-volume/config.yml. Se o arquivo for de propriedade do usuário root no host, será o mesmo root dentro do container? Se um usuário gtosss existe no host, é possível alternar para ele dentro do container e acessar o arquivo? E se criarmos um usuário gtosss dentro do container e concedermos a ele direitos sobre o arquivo, o host poderá acessar este arquivo sob o mesmo usuário? Se alguma dessas perguntas gera dúvidas, este artigo é para você.
É fundamental lembrar que o kernel opera com identificadores numéricos, os UIDs (User IDs) e GIDs (Group IDs), e não com nomes de usuários. A correspondência entre nomes de usuários e seus IDs é armazenada no arquivo /etc/passwd. Este arquivo contém linhas no formato nome_usuario:x:UID:GID:informacoes_do_usuario:/home/diretorio:/bin/shell. Por exemplo, gtosss:x:1000:1000:gtosss:/home/gtosss:/bin/bash. Para nossos experimentos, preparamos um ambiente com um arquivo docker-compose.yml que define um serviço alpine-playground utilizando a imagem alpine:3.22, com um volume montado de ./common para /common dentro do container. Criamos um diretório common no host e um arquivo message.txt dentro dele com o conteúdo 'hello from host'.
Ao executar o container e acessar seu shell, mesmo como root dentro do container, a visualização dos direitos do arquivo message.txt no volume montado revela os UIDs e GIDs diretamente (1000:1000), sem nomes de usuário associados, pois o arquivo /etc/passwd do container é independente. No entanto, o root do container consegue ler e escrever no arquivo sem problemas, mesmo quando o arquivo pertence ao root no host e tem permissões restritas. Isso demonstra que, em sistemas como o Ubuntu, o root dentro do container é, na prática, tratado como o mesmo root do sistema host pelo kernel Linux, o que pode ser um risco de segurança se volumes sensíveis forem montados. Quando um usuário gtosss existe no host com UID 1001, e criamos um usuário gtosss com UID 1000 dentro do container, o acesso ao arquivo é negado. Contudo, ao ajustar o UID do usuário gtosss no container para 1001, o acesso é concedido, confirmando que o kernel Linux verifica os IDs numéricos, não os nomes. Isso significa que, se um usuário com o mesmo UID existir no host, o container poderá acessar o arquivo com os direitos desse usuário.
Em sistemas com SELinux, como o Fedora Linux, a segurança é reforçada. Ao usar Podman, que por padrão opera em modo rootless e utiliza namespaces de usuário, o comportamento difere. O SELinux adiciona uma camada de controle baseada em contextos de segurança. Mesmo com permissões Unix clássicas, o acesso pode ser negado se o contexto SELinux do arquivo não for compatível com o contexto do container. A adição do sufixo :z ao volume no docker-compose.yml (ou equivalente no Podman) ajusta o contexto SELinux para permitir o compartilhamento entre containers. Além disso, o Podman, por padrão, utiliza user namespaces para mapear o root do container para um UID não privilegiado no host, aumentando significativamente a segurança em comparação com o Docker padrão, onde o root do container é o root do host. O mecanismo de namespaces do Linux, incluindo user namespaces, permite isolar recursos do sistema, e o Podman aproveita isso para criar um ambiente mais seguro, onde o root dentro do container não tem privilégios irrestritos no host.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Containers, ao contrário de máquinas virtuais, compartilham o kernel com o sistema host. Isso levanta uma questão crucial: como os direitos Unix se relacionam entre processos dentro de um container, containers vizinhos e a máquina host? Vamos considerar um cenário com um volume do tipo bind mount, que é um diretório do host montado dentro do container, contendo um arquivo config.yml em /some-volume/config.yml. Se o arquivo for de propriedade do usuário root no host, será o mesmo root dentro do container? Se um usuário gtosss existe no host, é possível alternar para ele dentro do container e acessar o arquivo? E se criarmos um usuário gtosss dentro do container e concedermos a ele direitos sobre o arquivo, o host poderá acessar este arquivo sob o mesmo usuário? Se alguma dessas perguntas gera dúvidas, este artigo é para você.
É fundamental lembrar que o kernel opera com identificadores numéricos, os UIDs (User IDs) e GIDs (Group IDs), e não com nomes de usuários. A correspondência entre nomes de usuários e seus IDs é armazenada no arquivo /etc/passwd. Este arquivo contém linhas no formato nome_usuario:x:UID:GID:informacoes_do_usuario:/home/diretorio:/bin/shell. Por exemplo, gtosss:x:1000:1000:gtosss:/home/gtosss:/bin/bash. Para nossos experimentos, preparamos um ambiente com um arquivo docker-compose.yml que define um serviço alpine-playground utilizando a imagem alpine:3.22, com um volume montado de ./common para /common dentro do container. Criamos um diretório common no host e um arquivo message.txt dentro dele com o conteúdo 'hello from host'.
Ao executar o container e acessar seu shell, mesmo como root dentro do container, a visualização dos direitos do arquivo message.txt no volume montado revela os UIDs e GIDs diretamente (1000:1000), sem nomes de usuário associados, pois o arquivo /etc/passwd do container é independente. No entanto, o root do container consegue ler e escrever no arquivo sem problemas, mesmo quando o arquivo pertence ao root no host e tem permissões restritas. Isso demonstra que, em sistemas como o Ubuntu, o root dentro do container é, na prática, tratado como o mesmo root do sistema host pelo kernel Linux, o que pode ser um risco de segurança se volumes sensíveis forem montados. Quando um usuário gtosss existe no host com UID 1001, e criamos um usuário gtosss com UID 1000 dentro do container, o acesso ao arquivo é negado. Contudo, ao ajustar o UID do usuário gtosss no container para 1001, o acesso é concedido, confirmando que o kernel Linux verifica os IDs numéricos, não os nomes. Isso significa que, se um usuário com o mesmo UID existir no host, o container poderá acessar o arquivo com os direitos desse usuário.
Em sistemas com SELinux, como o Fedora Linux, a segurança é reforçada. Ao usar Podman, que por padrão opera em modo rootless e utiliza namespaces de usuário, o comportamento difere. O SELinux adiciona uma camada de controle baseada em contextos de segurança. Mesmo com permissões Unix clássicas, o acesso pode ser negado se o contexto SELinux do arquivo não for compatível com o contexto do container. A adição do sufixo :z ao volume no docker-compose.yml (ou equivalente no Podman) ajusta o contexto SELinux para permitir o compartilhamento entre containers. Além disso, o Podman, por padrão, utiliza user namespaces para mapear o root do container para um UID não privilegiado no host, aumentando significativamente a segurança em comparação com o Docker padrão, onde o root do container é o root do host. O mecanismo de namespaces do Linux, incluindo user namespaces, permite isolar recursos do sistema, e o Podman aproveita isso para criar um ambiente mais seguro, onde o root dentro do container não tem privilégios irrestritos no host.
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
