Contenitori privilegiati e capacità

Question

Se si sta eseguendo un contenitore in modalità privilegiata, dispone di tutte le funzionalità del kernel o è necessario aggiungerli separatamente?

Answer 1

L'esecuzione in modalità privilegiata conferisce al contenitore tutte le funzionalità. Ma è buona norma dare sempre un contenitore i requisiti minimi di cui ha bisogno Se si guarda alla documentazione Docker si riferiscono anche a questo flag

capacità contenitore pieno (--privileged)

L'- il flag privilegiato fornisce tutte le funzionalità al contenitore e solleva anche tutte le limitazioni imposte dal controller cgroup del dispositivo. In altre parole, il contenitore può quindi eseguire quasi tutto ciò che l'host può fare. Questo flag esiste per consentire casi d'uso speciali, come l'esecuzione di Docker all'interno di Docker.

È possibile fornire funzionalità specifiche utilizzando il flag --cap-add. Vedere man 7 capabilities per ulteriori informazioni su tali funzionalità. I nomi letterali possono essere utilizzati, ad es. --cap-add CAP_FOWNER.

Answer 2

C'è un buon articolo che copre from RedHat covering this

Mentre contenitore finestra mobile in esecuzione come "root" ha meno privilegi rispetto root su host, ancora potrebbe essere necessario l'indurimento a seconda del caso d'uso (utilizzando come l'ambiente di sviluppo vs produzione condivisa cluster)

Answer 3

Dato che questo post è elevato su google rango di ricerca ho voluto aggiungere le informazioni sul motivo per cui non si vuole eseguire un contenitore utilizzando --privileged

sto facendo questo sul mio portatile che dispone di unità NVMe ma funzionerà per qualsiasi ospite.

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

primo luogo permette di fare qualcosa di minore, per testare il file system/proc

Dal contenitore:

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 ha fatto cambiare per il contenitore o per l'host?

$ cat /proc/sys/vm/swappiness 
61 

OOPS !, possiamo modificare arbitrariamente i parametri del kernel host. Ma questa è solo una situazione DOS, vediamo se possiamo raccogliere informazioni privilegiate dall'host genitore.

Consente di percorrere l'albero /sys e trovare il numero minore maggiore per il disco di avvio.

Nota: Ho due unità e contenitori NVMe sono in esecuzione sotto LVM su un'altra unità

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

OK consente di fare un file di dispositivo in una posizione in cui le regole dbus non esegue la scansione automatica.

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, possiamo leggere il disco di avvio, consente di creare un file di dispositivo per una delle partizioni. Mentre non possiamo montarlo come sarà aperto, possiamo comunque usare dd per 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 consente di montarlo e vedere se i nostri sforzi hanno funzionato !!!

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

Quindi, in pratica qualsiasi host contenitore che si consente a chiunque di lanciare un contenitore --privileged su è lo stesso di dare loro l'accesso root per ogni container su tale host.

Purtroppo il progetto finestra mobile ha scelto il modello di trusted computing, e al di fuori di autenticazione plugin non c'è modo per proteggersi da questo, in modo sempre errore sul lato di aggiungere caratteristiche necessarie vs. utilizzando --privileged