¿Es posible escalar privilegios y escapar de un contenedor Docker?

Un usuario en un host de Docker que tiene acceso al grupo de docker o privilegios para los comandos de sudo docker es efectivamente root (ya que puede hacer cosas como usar el docker para ejecutar un contenedor privilegiado o montar el sistema de archivos root dentro de un contenedor), que Es por eso que es muy importante controlar ese derecho.

Salir de un contenedor de Docker al host es un juego diferente y será más o menos difícil dependiendo de varios factores. Los posibles vectores incluyen: -

• Vulnerabilidades del núcleo. Los contenedores que se ejecutan en un host comparten el mismo kernel que el host, por lo que si hay un problema explotable en el kernel que se puede usar para salir del contenedor al host
• Mala configuración. Si un contenedor al que tiene acceso se está ejecutando con --privileged , es probable que pueda acceder al host subyacente.
• Sistemas de archivos montados. Si un contenedor que tiene monta un sistema de archivos host, es probable que pueda cambiar los elementos de ese sistema de archivos que le permitan escoltar privilegios al host.
• zócalo Docker montado. Una práctica relativamente común (y peligrosa) en los contenedores Docker es montar el zócalo de la ventana acoplable dentro de un contenedor, para permitir que el contenedor comprenda el estado del demonio de la ventana acoplable. Esto permite una ruptura trivial al host. Más información aquí

Si está buscando más información, recomendaría estos informes de NCC. Abusando de los Contenedores de Linux Privilegiados y No Privados y Entender y endurecer los contenedores Linix . También hay una presentación que hice que cubre algunas de estas cosas aquí .

Si está interesado en el endurecimiento de Docker, también le recomiendo echar un vistazo a la Norma de seguridad CIS .

Con los medios normales, no. Docker fue diseñado intencionalmente en este concepto de seguridad.

Utiliza la funcionalidad de espacio de nombres del kernel para separar los procesos que se ejecutan en un contenedor de los que se ejecutan en el host. Si se encuentra una forma, se considerará como un agujero de seguridad y se cerrará lo antes posible.

Aunque podría haber ajustes de configuración de todo el sistema. En general, los contenedores de la ventana acoplable pueden ejecutarse con SYS_ADMIN , lo que esencialmente significa que son capaces de cambiar las direcciones IP y muchas otras funciones que normalmente están disponibles en la máquina host. Si un contenedor se ejecuta con SYS_ADMIN , en realidad no está más protegido como una tarea que se ejecuta en chroot.

Aunque esta configuración se usa principalmente si un contenedor de ventana acoplable se ejecuta como un servicio, como un demonio en un servidor Linux. En las computadoras portátiles normales, como su uso previsto, todo se ejecuta de forma predeterminada. Si no fuera así, los usuarios de la ventana acoplable tendrían que confiar en todos los desarrolladores de contenedores que están utilizando. Ahora solo tienen que confiar en los desarrolladores de la ventana acoplable.

En la versión de Windows de la ventana acoplable, incluso esto no sería suficiente. La ventana acoplable de Windows inicia una máquina virtual de Linux con HyperV y ejecuta los contenedores de la ventana acoplable en esta máquina virtual de Linux. Salir de un contenedor solo significaría un permiso de root en esta máquina virtual, para salir del cliente que tenía que encontrar un agujero también en el HyperV.