È possibile eseguire l'escalation dei privilegi e l'escaping da un contenitore Docker?

Un utente su un host Docker che ha accesso al gruppo docker o ai privilegi per sudo comandi docker è effettivamente root (dato che puoi fare cose come usare la finestra mobile per eseguire un contenitore privilieged o montare il filesystem di root all'interno di un container), che è il motivo per cui è molto importante controllarlo.

L'espulsione da un contenitore Docker verso l'host è un gioco diverso e sarà più o meno difficile a seconda di una serie di fattori. I vettori possibili includono: -

• Vulnerabilità del kernel. I contenitori in esecuzione su un host condividono lo stesso kernel dell'host, quindi se c'è un problema sfruttabile nel kernel che potrebbe essere utilizzato per rompere il contenitore verso l'host
• Cattiva configurazione. Se un contenitore a cui hai accesso è in esecuzione con --privileged , è probabile che tu possa accedere all'host sottostante.
• File system montati. Se un container monta un filesystem host, è probabile che tu possa cambiare gli elementi in quel filesystem, il che potrebbe permetterti di escludere i privilegi dall'host.
• Presa Docker montata. Una pratica relativamente comune (e pericolosa) nei contenitori Docker consiste nel montare il socket docker all'interno di un contenitore, per consentire al contenitore di comprendere lo stato del daemon della finestra mobile. Ciò consente una banale interruzione dell'host. Maggiori informazioni qui

Se stai cercando ulteriori informazioni, ti consiglio questi white paper da NCC. Contenitori Linux privilegiati e non privilegiati e Contenitori di Linix per il contenimento e l'indurimento . C'è anche una presentazione che ho fatto che copre alcune di queste cose qui .

Se sei interessato alla tempra Docker, ti consiglio anche di dare un'occhiata a Standard di sicurezza CIS .

Con mezzi normali, no. Docker è stato intenzionalmente progettato su questo concetto di sicurezza.

Utilizza la funzionalità namespace del kernel per separare i processi in esecuzione in un contenitore da quelli in esecuzione su host. Se fosse trovato un modo, sarebbe considerato come un buco di sicurezza e sarebbe chiuso al più presto.

Anche se potrebbero esserci impostazioni di configurazione a livello di sistema. In genere, i contenitori docker possono essere eseguiti con SYS_ADMIN , il che significa essenzialmente che sono in grado di cambiare gli indirizzi IP e molte altre funzioni disponibili normalmente sul computer host. Se un contenitore viene eseguito con SYS_ADMIN , in sostanza non è più protetto come attività in esecuzione in chroot.

Sebbene questa configurazione sia utilizzata principalmente se un contenitore docker viene eseguito come un servizio, come un daemon su un server Linux. Nei laptop normali, come previsto, tutto viene eseguito come predefinito. Se non fosse così, gli utenti di docker dovrebbero avere fiducia in tutti gli sviluppatori di container che stanno utilizzando. Ora devono fidarsi solo degli sviluppatori della finestra mobile.

Sulla versione Windows della finestra mobile, anche questo non sarebbe sufficiente. La finestra mobile di Windows avvia una macchina virtuale Linux con HyperV e esegue i contenitori finestra mobile in questa macchina virtuale Linux. Scoppiare da un contenitore significherebbe solo un permesso di root su questa VM, per irrompere nel client è stato necessario trovare un buco anche in HyperV.