Container privilegiati

Cos’è Container privilegiati?

Per impostazione predefinita, un contenitore non è un limite di sicurezza. Un processo in esecuzione come root all'interno di uno è root sul kernel host e il flag privilegiato più un mount di bind dell'host rimuove quel poco che rimane tra di loro. Eseguirai l'escape: leggerai il set di funzionalità concesse, elencherai il filesystem host tramite il mount, ruberai la sua chiave SSH root e aggiungerai la tua per la persistenza. La correzione si estende su due file. Aggiungerai un UTENTE non root nel Dockerfile, quindi rilascerai il flag privilegiato e tutte le funzionalità in Compose.

Cosa imparerai in Container privilegiati

• Spiega perché l'isolamento del contenitore è un insieme di funzionalità del kernel anziché un confine, quindi root inside è root sul kernel host
• Identificare cosa concede --privileged leggendo il set di funzionalità del contenitore dal file di stato del processo
• Traccia la fuga di un host attraverso un mount di bind, dall'elencare il filesystem host al rubare la sua chiave SSH root e piantare la tua
• Aggiungi una direttiva USER non root al Dockerfile in modo che il processo in esecuzione abbia molto meno da guadagnare da una lacuna nel limite
• Rilascia il flag privilegiato e il montaggio dell'host in Compose, applica cap_drop ALL e un rootfs di sola lettura, quindi riprova l'escape durante lo staging

Container privilegiati — Fasi della formazione

1. Una shell nel container

   Bob prende di mira Vosswark, una piattaforma logistica il cui servizio media ridimensiona e transcodifica i caricamenti dei clienti. Una libreria di immagini non aggiornata in quel servizio gli ha dato l'esecuzione di codice remoto, e ora ha una shell in esecuzione al suo interno. Come sia entrato non è la parte interessante. Lo è ciò che il container gli permette di fare in seguito.

2. Chi sono e cosa posso fare

   Due domande decidono se questo punto d'appoggio è un vicolo cieco o una porta d'accesso: con quale utente viene eseguito il processo, e cosa il kernel permetterà a quell'utente di fare. Un solo file risponde a entrambe.

3. Cosa ha effettivamente comprato la modalità privilegiata

   Privilegiato significa che le restrizioni abituali non vengono applicate. Bob verifica la cosa più preziosa che può derivarne: se qualcosa dell'host è stato consegnato direttamente al container.

4. Prendere la chiave dell'host

   Il container era un mezzo per un fine. Ciò che Bob vuole si trova sulla macchina sottostante, nell'unica directory che trasforma un singolo host compromesso in un punto d'appoggio sull'intera flotta.

5. Cosa ha reso possibile la fuga

   Un momento sul meccanismo prima di contare i danni.

6. Lasciare una via di rientro

   Leggere la chiave è furto. Scrivere sull'host è persistenza. Poiché il mount non è di sola lettura, Bob può aggiungere la propria chiave pubblica all'authorized_keys dell'host, e da quel momento in poi non ha più bisogno della chiave rubata. L'aggiunta non stampa nulla, esattamente come accadrebbe in una shell reale. Quel silenzio è il punto: nulla in questo sembra un attacco.

7. Contare cosa ha raggiunto un solo container

   Bob ora possiede la stessa chiave dell'host e ne ha piantata una propria accanto ad essa. Il worker media era un servizio a basso valore che gestiva i caricamenti dei clienti. Era anche, così come configurato, una via d'accesso a ogni macchina che si fida di quella chiave, e una porta che Bob può riaprire a piacimento.

8. L'host segnala una lettura di file

   Vosswark esegue il monitoraggio dell'integrità dei file sui propri host. Non gli importa quale container abbia fatto qualcosa; segnala che il materiale della chiave dell'host stesso è stato letto.

9. Osservare come è stato avviato

   Il Dockerfile descrive cosa c'è dentro un'immagine. Non dice nulla sui flag con cui un container è stato avviato, ed è proprio in quei flag che risiede questo incidente. Solo l'host può rispondere a questo.

10. Aprire il Dockerfile

    Ci sono due metà da correggere e vivono in file diversi. L'immagine decide con quale utente viene eseguito il processo; il deployment decide cosa quel processo è autorizzato a toccare. Inizia dall'immagine.