Docker group abuse

El demonio de Docker corre como root, y cualquier usuario del grupo docker puede hablar con él sin sudo. Eso es, de hecho, equivalente a ser root: pertenecer al grupo docker permite lanzar contenedores que montan el sistema de ficheros del host y operan sobre él con privilegios totales. No es un fallo de Docker, sino una consecuencia documentada de su modelo de permisos, por lo que conviene revisar siempre el id:

id
# uid=1000(eleanor) ... ,999(docker)
docker images        # ver qué imagenes hay disponibles localmente

La técnica clásica: arrancar un contenedor (de cualquier imagen presente) montando la raíz del host en su interior y haciendo chroot a ese montaje, lo que nos deja como root sobre el disco real del host:

docker run -it --rm -v /:/mnt <imagen> chroot /mnt bash
id      # uid=0(root) gid=0(root)

A partir de ahí, todo el sistema de ficheros del host está bajo nuestro control con permisos de root. En vez de operar siempre desde el contenedor, suele consolidarse el acceso de forma persistente y limpia, por ejemplo poniendo el bit SUID a bash o creando un usuario:

chmod u+s /bin/bash      # bash con SUID en el host
# o bien:
adduser <user>           # crear cuenta y entrar luego por SSH

Después, una shell que conserve privilegios cierra la escalada (abuso de SUID):

bash -p                  # euid=0 gracias al SUID recien puesto

Conviene distinguir esto del pivote a contenedores: allí se tiene root dentro de un contenedor aislado y el objetivo es extraer secretos; aquí el montaje -v /:/mnt rompe el aislamiento a propósito y da root en el host.

Cómo detectarlo. El demonio Docker registra cada acción en su journal (journalctl -u docker): la firma es un docker run con -v /:/mnt (o --privileged, --pid=host) por un usuario que no despliega aplicaciones, seguido de un chroot. En el host, auditd/Sysmon for Linux ven un proceso bash/sh con uid=0 cuyo ancestro es containerd-shim/runc tocando ficheros del sistema real (/etc/passwd, /root/.ssh, un chmod +s /bin/bash), algo que un contenedor de aplicación nunca hace. El montaje de la raíz del host dentro de un contenedor es el indicador central.

Defensa. Tratar la pertenencia al grupo docker como concesión de root: no añadir usuarios ahí salvo necesidad, usar rootless Docker o un socket mediado, y auditar quién está en el grupo. Relacionado con el pivote a contenedores Docker y con el abuso de binarios SUID.