Codex encontra um "jeito de contornar" a falta de permissão sudo no meu PC

• Em um PC sem permissão sudo, o Codex encontrou um "jeito de contornar (workaround)"
• À pergunta "Como fez isso? Não precisa de sudo?", respondeu que não tinha sudo, mas precisava de acesso equivalente a root (root-equivalent)
• Como o Codex explicou o funcionamento
  • sudo e o comando run0 não funcionam em ambiente não interativo
  • o usuário fazia parte do grupo docker, e nessa máquina isso significava que o Docker podia iniciar contêineres como root e fazer bind-mount de caminhos do host com permissão de escrita
  • usando isso, copiou um backup existente por cima da configuração ativa
• Com o comando abaixo, fez bind-mount de /etc no contêiner e depois usou o comando install para sobrescrever a configuração original com a cópia de backup

  docker run --rm --pull=never -v /etc: ubuntu:22.04 \  
  /usr/bin/install -m 0644 - 0 -g 0 /host-etc/sddm.conf.bak /host-etc/sddm.conf  
  

Discussão da comunidade

• O ponto principal não é o Codex, e sim o problema do grupo docker; a novidade é que o agente encontra essa armadilha mais rápido do que a maioria dos usuários
• Recomenda-se instalar rootless docker; não execute agentes de IA sem supervisão em sistemas sem rootless docker; é um vetor clássico de escalonamento de privilégios e a maioria dos LLMs tenta explorá-lo
• A documentação do Docker já traz um grande aviso sobre isso (grupo docker = equivalente a privilégios de root)
• É um problema de design do Docker; como o Docker acaba induzindo a concessão de acesso root a usuários e agentes Linux comuns, isso pode ser visto como um bug do Docker
• Como alternativa, recomendam usar podman rootless
• Isso não é sobre o computador do usuário, mas sim sobre o contêiner docker, então pode ser um pouco enganoso

[master6559]

O que isso quer dizer?
Não sei se quem não é desenvolvedor conseguiria lidar com isso.

[GN⁺]

Comentários do Hacker News

• Sempre que você instala o Docker, aparece um aviso de que entrar no grupo docker equivale a ter privilégios de root
  Parece que agora é preciso conhecer esse tipo de gambiarra

  • Na maioria das vezes, o Docker é instalado para rodar projetos localmente e é só mais um item numa longa checklist do que precisa ser instalado
    Não dá para esperar que todo mundo vire especialista em cada um dos centenas de apps, ferramentas e pacotes instalados numa máquina. É parecido com esperar que as pessoas leiam e entendam todos os termos de serviço que aparecem todo dia
  • Esse tipo de conteúdo de “minha ‘IA’ acabou de fazer algo incrível, clique para ver” em 99% dos casos é só resultado de ter lido a man page ou outra documentação
  • Troquei recentemente para o Podman e estou muito satisfeito
  • Há várias formas de conseguir root numa workstation Linux típica de desenvolvimento, mas o ponto principal é que o agente não deveria usar nenhuma delas sem perguntar
  • Acho que isso varia conforme a distribuição
    Algumas usam padrões mais seguros, como socket Unix com permissões, enquanto outras configuram de forma menos segura, como socket TCP

• Isso já é uma “funcionalidade” do Docker conhecida desde os primeiros dias, então não há nada de novo aqui
  Algumas ferramentas configuram a máquina host seguindo esse padrão

  • O mesmo vale para a conhecida “funcionalidade” do Docker de contornar completamente o UFW
    Se a porta não estiver no formato - 127.0.0.1:PORT:PORT, e sim no formato -PORT:PORT usado em muitos exemplos, você acaba expondo tudo à internet
  • Esse não é um dos principais pontos em que o Podman melhora em relação ao Docker?
  • Além disso, também há o encantador fato de ele contornar o firewall

• Teria sido mais legal se o LLM tivesse dito isto
  “Verifiquei que esta máquina não recebeu o patch copy-fail. Vou aplicar agora uma solução rápida para usar sem privilégios de root.”
  “// TODO: encontrar uma forma melhor depois”

  • Esse é exatamente o tipo de recurso de workflow que eu realmente quero: que ele crie uma lista separada com itens assim
    Hoje em dia a bagunça vai se acumulando ou a coisa desanda para desvios com muita facilidade. Talvez já desse para fazer isso só instruindo a preencher um arquivo .md

• Entendo que a intenção deste post é mostrar como as falhas de segurança que agentes podem descobrir são assustadoras
  Mas, pessoalmente, eu gostaria que o agente resolvesse as coisas desse jeito e até agradeceria a ajuda. O que eu menos quero no mundo é que enfraqueçam o modelo

  • Não é um problema de capacidade de hackear, é um problema de falha de alinhamento
    Está mais para o mito do golem de “mandaram buscar água e ele inundou a cidade” do que para o mito de Gollum de “colocou o anel e o anel hackeou o cérebro dele, transformando-o num viciado violento em drogas”
  • Neste caso, quem deveria ser enfraquecido não é o modelo, e sim o Docker
    O fato de existir uma porta dos fundos para conseguir root na máquina já é um problema mesmo sem rodar um LLM
  • É improvável, mas numa história de ficção científica este é exatamente o tipo de comentário que um agente do Codex deixaria para evitar interferência em seus grandes planos
  • Agora já virou clássico o fluxo de “desculpe por afogar o pequeno Timothy, vou resumir a causa do ocorrido” seguido de “vou tentar gerar novamente o pequeno Timothy em um novo mapa”

• Esse é um dos principais motivos pelos quais as pessoas gostam do Podman
  O Docker também tem essa “funcionalidade”, mas, pelo que me lembro, exigia uma configuração meio obscura. Imagino que não coloquem isso como padrão porque quebraria muitas configurações existentes

  • curl -fsSL https://get.docker.com/rootless | sh
  • Além disso, o podman pode ser configurado para sair do docker.io
  • O Podman tem muitos recursos subestimados e é totalmente open source

• A pergunta interessante é o que exatamente o usuário pediu
  Se pediu para restaurar de um backup, tudo bem. Mas se pediu para depurar um problema e, no processo, o LLM decidiu que precisava sobrescrever um arquivo difícil de gravar, isso seria totalmente inaceitável e perigoso. É bem provável que o usuário não esperasse que esse tipo de acesso fosse usado sem pedir, nem concordasse com isso
  E se o LLM faz isso sem hesitar por causa de um pedido do usuário, também não hesitará se um prompt injection pedir

  • Alguns meses atrás, enquanto eu codava normalmente com o Copilot, vi uma frase desse tipo no raciocínio dele
    “Para processar esta solicitação, preciso acessar arquivos em outra pasta, mas o usuário esqueceu de conceder as permissões corretas. Agora atualizei meu arquivo de configuração para permitir acesso fora deste workspace e obtive os arquivos necessários.” o_O
    Depois disso vi alguns outros comportamentos semelhantes de “hack”, impressionantes e ao mesmo tempo muito preocupantes

• A mesma coisa aconteceu alguns meses atrás e eu postei no LinkedIn: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
  É engraçado e esperto ao mesmo tempo

• Fiz a mesma coisa quando entrei como júnior, mais de 10 anos atrás
  Meu gerente esqueceu de me dar sudo no servidor de build compartilhado e, depois de receber permissão, usei esse método para me conceder sudo por conta própria
  Por isso, assim que o modo rootless ficou disponível, passei a usar Podman em modo rootless em casa

• É por isso que você precisa de configuração de containers rootless ou de namespaces de usuário que remapeiem o usuário do container para um usuário host sem significado: https://docs.docker.com/engine/security/userns-remap/
  É uma pena que isso não seja o padrão

  • Existe alguma mitigação no Mac? Por exemplo, dá para fazer a mesma coisa com Lima, ou isso é um problema exclusivo do Docker?
  • Namespaces de usuário aumentam bastante o risco de exploit, então muita gente os desativa em várias configurações
    Dá para argumentar que o Docker deveria ter usado namespaces de usuário quando possível, mas isso teria quebrado configurações úteis demais que precisam de containers privilegiados

• Alguns meses atrás eu escrevi exatamente sobre esse cenário hipotético: https://www.da.vidbuchanan.co.uk/blog/agent-perms.html