Falha no Omarchy permitia que qualquer processo do usuário virasse root sem senha

Uma falha na configuração padrão do Omarchy, a distribuição Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → baseada em Arch criada por David Heinemeier Hansson (DHH), permitia que praticamente qualquer processo rodando na sessão do usuário escalasse para root sem senha, sem sudo e sem qualquer prompt de privilégio. O problema foi reportado de forma privada, já foi corrigido, e a orientação para quem usa o sistema é direta: atualize para a versão 4.0.1.

O que causava o problema

O Omarchy configurava o usuário padrão como membro do grupo docker do Linux. Isso permite rodar comandos como docker run ... sem digitar sudo, o que soa conveniente, mas tem uma implicação de segurança que a própria documentação do Docker alerta explicitamente: pertencer ao grupo docker equivale a conceder privilégios de root ao usuário.

No Arch, o daemon do Docker roda como root e escuta no socket /var/run/docker.sock. Membros do grupo docker conseguem se comunicar com esse socket, e um processo com acesso a ele pode pedir ao daemon (que é root) para subir um container como root, montar partes arbitrárias do sistema de arquivos do host dentro dele e operar sobre esses arquivos com privilégio total.

A prova de conceito publicada pelo pesquisador mostra a mecânica de forma didática. Numa instalação afetada, ler um arquivo protegido falha:

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

Mas o mesmo usuário aparece no grupo docker (id 967 no exemplo):

$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)

E aí o arquivo cai sem resistência, usando o Docker como intermediário root:

$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...
bin:!*:...
daemon:!*:...

O comando é lançado por um processo de usuário comum, mas o acesso real ao sistema de arquivos acontece através de um daemon rodando como root.

Por que isso afeta a sessão inteira

O detalhe que transforma um risco teórico em problema imediato: grupos suplementares no Linux são herdados por processos filhos. Ao inspecionar a árvore de processos abaixo da instância systemd --user, o grupo docker aparecia em praticamente todo processo normal da sessão.

Na prática, quase todo lugar onde código não confiável pode rodar passa a ter um caminho para root, incluindo:

• agentes de codificação de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → e seus harnesses
• navegadores web
• editores e IDEs
• scripts de npm
• ferramentas diversas de desenvolvimento
• processos em segundo plano

Em outras palavras: o comprometimento de um aplicativo comum do usuário viraria comprometimento total da máquina. Para quem roda pacotes de terceiros, executa build scripts arbitrários ou deixa agentes de IA operarem com autonomia, essa é exatamente a superfície de ataque que mais cresce.

O ponto sobre defaults inseguros

O pesquisador destaca que a configuração era opt-out, não opt-in. O usuário não precisava sequer usar Docker para carregar o risco: o tradeoff de segurança já vinha aplicado na conta padrão, sem ser explicado. Pior, a documentação de ferramentas de desenvolvimento do Omarchy mencionava que instalava "as mudanças de grupo de usuário necessárias para você rodar o Docker como usuário normal e não como root", frase da qual um leitor razoavelmente concluiria que o Docker estava configurado em modo rootless. Não estava.

A falha afeta versões anteriores à 4.0.1, e foi confirmada também na última ISO da série 3.x (a 3.8.4). O grupo docker foi introduzido no default em 1º de junho de 2025 e removido em 24 de agosto de 2026.

A reação da comunidade

O thread no Hacker News concentrou duas linhas de discussão. A primeira, quase unânime, é que o Docker daemon-based não deveria estar no default de uma distro para desenvolvedores em 2026. No thread, antiloper foi direto: "Installing docker by default is completely insane. What are they doing? Rootless podman has been around for many years at this point."

O próprio autor do relatório recomenda o Podman como alternativa: por ser daemonless, os containers rodam como processos filhos normais em seus próprios user namespaces e não exigem acesso root.

Houve também quem relativizasse o impacto num desktop de usuário único. qweqwe14 argumentou que acesso ao diretório home já é gravíssimo por si só e que há inúmeros outros caminhos para root, e exitb ponderou: "It's not great, but I'm not sure this should be framed as Omarchy-specific, when it's a very common setup to add regular user to the docker group."

Um comentário resume por que esse tipo de misconfiguração deixou de ser acadêmica na era dos agentes:

Lol. This misconfiguration is so common and so trivial that LLMs have been known to exploit it unprompted, to complete their task.

Retr0id

O que fazer

Para quem usa Omarchy, o passo obrigatório é atualizar para a 4.0.1. Mas o alerta vale para qualquer máquina de desenvolvimento Linux, não só a distro em questão: se o seu usuário está no grupo docker, verifique com id. Se estiver e você não quiser esse tradeoff, avaliar a migração para Podman rootless é o caminho apontado tanto pelo pesquisador quanto pela comunidade.

O relator credita a resposta rápida do projeto como sinal saudável e atribui a decisão a um descuido, mas registra desconforto com o processo de decisão de segurança do Omarchy. Fica em aberto o quanto distribuições voltadas a desenvolvedores vão revisar seus defaults num momento em que a máquina do dev é alvo de alto valor, com credenciais em dotfiles e guardrails desligados por conveniência.

Fontes: Hacker News · Reações no Hacker News