Falha no Omarchy permitia qualquer processo escalar para root

A falha

Uma falha de segurança na configuração padrão do Omarchy permitia que essencialmente qualquer processo executado na sessão de desktop do usuário escalasse para root, sem senha, sem sudo e sem aviso de privilégio. O problema foi reportado privadamente pelo descobridor, corrigido e os detalhes foram publicados agora para que os usuários atualizem para a versão 4.0.1.

Mecanismo técnico

O Omarchy configurava seu usuário padrão como membro do grupo docker do Linux, permitindo executar comandos como docker run sem sudo. No Arch, o daemon do Docker roda como root e escuta em /var/run/docker.sock; membros do grupo podem se comunicar com esse socket. O próprio Docker alerta explicitamente que o grupo docker concede privilégios de nível root. Um processo com acesso ao socket pode pedir ao daemon, que roda como root, para lançar um container, montar partes arbitrárias do sistema de arquivos do host e operar nelas como root.

Prova de conceito e alcance

Em uma instalação afetada, cat /etc/shadow era negado ao usuário comum, mas docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow lia o arquivo, porque o acesso real ao sistema de arquivos era feito pelo daemon root.

Como grupos suplementares do Linux são herdados pelos processos filhos, a falha afetava toda a sessão do usuário: caminhar pela árvore de processos abaixo do systemd --user mostrou o grupo Docker presente em praticamente todos os processos normais da sessão. Isso incluía agentes de codificação com IA, navegadores, editores e IDEs, scripts npm, ferramentas de desenvolvimento e processos em segundo plano. Ou seja, o comprometimento de um aplicativo comum do usuário poderia se tornar imediatamente um comprometimento completo da máquina.

Padrões de segurança e documentação

A configuração era opt-out, não opt-in: o usuário não precisava usar Docker para receber o tradeoff de segurança, que foi aplicado à conta padrão sem explicação. Segundo o autor, padrões sensíveis a segurança importam porque muitos usuários presumem razoavelmente que o sistema é seguro por padrão e pediria consentimento para opções menos seguras.

A documentação do Omarchy mencionava o grupo Docker ao dizer que instalava as mudanças de grupo necessárias para "rodar Docker como usuário normal e não como root". O autor argumenta que a implicação de segurança era quase oposta ao que um leitor poderia inferir de "não como root", pois a leitura sugeriria um modo rootless que não existia.

Versões afetadas e cronologia

A falha afetava versões anteriores à 4.0.1, incluindo a ISO 3.x mais recente (3.8.4), testada pelo autor. A linha do tempo: em 1º de junho de 2025 a adesão ao grupo Docker foi introduzida; em 2 de junho foi desabilitada temporariamente; em 17 de junho foi reativada; e em 24 de agosto de 2026 foi removida da configuração padrão.

Contexto mais amplo e avaliação do autor

O autor observa que, com a IA produzindo cada vez mais CVEs de alta gravidade contra infraestrutura central, segurança precisa estar no topo das prioridades, especialmente para autores de distribuições voltadas a desenvolvedores. Há muitos relatos recentes de máquinas de desenvolvedores comprometidas, com acesso usado para contaminar a cadeia de suprimentos de software ou explorar sistemas de produção, porque desenvolvedores são alvos de alto valor, desabilitam proteções por conveniência, guardam credenciais em dotfiles em texto puro e acumulam acessos - algo que, segundo ele, precisa mudar.

Ele afirma acreditar que foi um descuido de DHH por não conhecer as implicações de adicionar o grupo docker, nota que nenhuma distribuição toma decisões perfeitas de segurança e elogia a velocidade da resposta ao reporte. Ainda assim, diz que não é a primeira vez que encontra problemas de segurança no Omarchy e que não confia no processo atual de tomada de decisão para garantir a segurança que espera de sua distribuição, embora haja muito a gostar no projeto.

Alternativa

Para quem não quer conceder root para rodar containers no Linux, o autor recomenda Podman, que é daemonless: os containers rodam como processos filhos normais em namespaces de usuário próprios, sem acesso root. Ele usa Podman há vários meses e afirma que ele substituiu totalmente seus fluxos de trabalho com Docker.