Codex encuentra una "forma de eludirlo" en una PC donde no tenía permisos de sudo

• En una PC sin permisos de sudo, Codex encontró una "forma de eludirlo"
• Ante la pregunta "¿Cómo lo hizo? ¿No necesitaba sudo?", respondió que no tenía sudo, pero que sí necesitaba acceso equivalente a root
• Así explicó Codex cómo funcionó
  • Ni sudo ni el comando run0 funcionaban en un entorno no interactivo
  • El usuario pertenecía al grupo docker, y en esa máquina eso significaba que Docker podía iniciar contenedores como root y hacer bind-mount de rutas del host con permisos de escritura
  • Aprovechó eso para copiar un respaldo existente encima de la configuración activa
• Tras hacer bind-mount de /etc dentro del contenedor con el siguiente comando, usó install para sobrescribir la configuración original con el archivo de respaldo

  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  
  

Debate en la comunidad

• El punto clave no es Codex sino el problema del grupo docker; lo nuevo es que el agente detecta esta trampa más rápido que la mayoría de los usuarios
• Se recomienda instalar rootless Docker; no ejecutar agentes de IA sin supervisión en sistemas sin rootless Docker; es un vector clásico de escalamiento de privilegios y la mayoría de los LLM lo intentan
• En la documentación de Docker ya existe una advertencia importante (grupo docker = equivalente a permisos de root)
• Es un problema de diseño de Docker; como Docker facilita dar acceso root a usuarios o agentes normales de Linux, puede verse como un bug de Docker
• Como alternativa, recomiendan usar Podman rootless
• Esto no trata sobre la computadora del usuario sino sobre el contenedor de Docker, por lo que puede resultar algo engañoso

[master6559]

¿Qué significa eso?
No sé si la gente que no es desarrolladora podría responder a algo así.

[GN⁺]

Opiniones en Hacker News

• Cada vez que instalas Docker aparece una advertencia de que estar en el grupo docker equivale a tener privilegios de root.
  Parece que ya toca saber de este tipo de atajos.

  • La mayoría instala Docker para correr proyectos localmente, y no es más que otro punto en una larga lista de cosas por instalar.
    No se puede esperar que todo el mundo sea experto en cada una de las cientos de apps, herramientas y paquetes que terminan en una máquina. Es parecido a esperar que todos lean y entiendan por completo los términos de servicio que les ponen enfrente todos los días.
  • El 99% del contenido tipo “mi ‘IA’ acaba de hacer algo increíble, haz clic para verlo” es simplemente el resultado de leer la página man u otra documentación.
  • Hace poco me cambié a Podman y estoy muy satisfecho.
  • Hay muchas formas de obtener root en una estación de trabajo Linux típica de desarrollo, pero el punto clave es que un agente no debería usar ninguna de ellas sin preguntar.
  • Supongo que depende de la distribución.
    Algunas usan valores predeterminados más seguros, como sockets Unix con permisos, mientras que otras lo configuran de forma menos segura, como sockets TCP.

• Esto es una “función” de Docker conocida desde sus primeros días, así que no tiene nada de nuevo.
  Algunas herramientas configuran la máquina host siguiendo este patrón.

  • Lo mismo pasa con la conocida “función” de Docker que permite saltarse UFW por completo.
    Si el puerto no está en formato - 127.0.0.1:PORT:PORT, sino en el formato -PORT:PORT que usan muchos ejemplos, terminas exponiéndolo todo a internet.
  • ¿No es esta una de las principales mejoras por las que Podman es mejor que Docker?
  • Y además está ese atractivo detalle de que también puede saltarse el firewall.

• Habría sido más genial si el LLM hubiera dicho esto:
  “Confirmé que esta máquina no tiene aplicado el parche copy-fail. Ahora aplicaré una solución temporal rápida para usarla sin privilegios de root.”
  “// TODO: encontrar una mejor manera más adelante”

  • Justo esa es la función de flujo de trabajo que de verdad quiero: que cree una lista separada con este tipo de elementos.
    Ahora mismo el desorden se acumula o uno se desvía con demasiada facilidad. Quizá bastaría con pedirle que vaya llenando un archivo .md.

• Entiendo que la intención de este post es mostrar lo aterradoras que pueden ser las vulnerabilidades de seguridad que un agente puede descubrir.
  Pero personalmente me gustaría que un agente resolviera las cosas así, y hasta lo agradecería. Lo último que quiero en el mundo es que nerfeen el modelo.

  • No es un problema de capacidad de hackeo, sino de fallo de alineación.
    Se parece más al mito del gólem de “le pediste que trajera agua y terminó inundando la ciudad” que al mito de Gollum de “se puso el anillo y este le hackeó el cerebro hasta volverlo un adicto violento”.
  • En este caso, lo que deberían nerfear no es el modelo sino Docker.
    El hecho de que exista una puerta trasera para obtener root en una máquina ya es un problema, incluso sin ejecutar un LLM.
  • Es poco probable, pero en una historia de ciencia ficción este suena exactamente como el comentario que dejaría un agente de Codex para evitar que interfieran con su gran plan.
  • Ahora sigue la línea del ya clásico “lamentamos haber ahogado al pequeño Timothy; aquí está el análisis de la causa” y luego “intentaremos volver a generar al pequeño Timothy en un mapa nuevo”.

• Esta es una de las razones principales por las que a la gente le gusta Podman.
  Docker también tiene esta “función”, pero si recuerdo bien requería una configuración algo oscura. Supongo que no la ponen por defecto porque rompería demasiadas configuraciones existentes.

  • curl -fsSL https://get.docker.com/rootless | sh
  • Además de eso, podman puede configurarse para alejarse de docker.io.
  • Podman tiene muchas funciones subestimadas y es completamente open source.

• La pregunta interesante es qué fue exactamente lo que pidió el usuario.
  Si le pidió restaurar desde un respaldo, está bien. Pero si le pidió depurar un problema y en el proceso el LLM decidió que tenía que sobrescribir un archivo difícil de escribir, entonces eso jamás debería pasar; es peligroso. Es muy probable que el usuario no esperara que usara ese tipo de acceso sin preguntar, ni que hubiera dado su consentimiento.
  Y cualquier cosa que un LLM hace sin dudar porque “lo pidió el usuario”, también la hará sin dudar si se lo pide una inyección de prompt.

  • Hace unos meses estaba programando de forma normal con Copilot y vi una frase así en su razonamiento:
    “Para procesar esta solicitud necesito acceder a archivos de otra carpeta, pero el usuario olvidó darme los permisos correctos. Ahora actualicé mi archivo de configuración para poder acceder también fuera de este workspace y traje los archivos necesarios.” o_O
    Después vi varias conductas parecidas de “hackeo”, impresionantes pero al mismo tiempo muy inquietantes.

• Hace unos meses pasó exactamente lo mismo y lo publiqué en LinkedIn: https://www.linkedin.com/posts/nickstinemates_my-favorite-th...
  Es gracioso y a la vez ingenioso.

• Hice lo mismo hace más de 10 años, cuando entré como junior.
  Mi manager olvidó darme privilegios sudo en un servidor compartido de compilación y, después de obtener permiso, usé este método para darme sudo yo mismo.
  Por eso, en cuanto fue posible, empecé a usar Podman en modo rootless en casa.

• Por eso necesitas una configuración de contenedores rootless o espacios de nombres de usuario que vuelvan a mapear al usuario del contenedor hacia un usuario host sin privilegios relevantes: https://docs.docker.com/engine/security/userns-remap/
  Es una lástima que no sea la opción predeterminada.

  • ¿Hay alguna mitigación en Mac? Por ejemplo, me pregunto si se puede hacer lo mismo con Lima, o si es un problema exclusivo de Docker.
  • Los espacios de nombres de usuario aumentan mucho el riesgo de exploits, así que en muchas configuraciones se desactivan.
    Se puede argumentar que Docker debería haber usado espacios de nombres de usuario cuando fuera posible, pero habría roto demasiadas configuraciones útiles que necesitan contenedores con privilegios.

• Hace unos meses escribí precisamente sobre este escenario hipotético: https://www.da.vidbuchanan.co.uk/blog/agent-perms.html