Confini di sicurezza tra Docker e LXC per i servizi domestici privilegiati

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Docker vs LXC Security Boundaries for Privileged Home Services

Docker è la scelta predefinita più sicura quando un servizio domestico con privilegi può rimanere un'unica applicazione dichiarata con mount limitati. LXC è più ordinato quando ha davvero bisogno di un piccolo sistema Linux, ma nessuno dei due crea un confine separato a livello di kernel.

La questione decisiva non è quale etichetta sembri offrire un maggiore isolamento. Entrambi si basano sul confinamento del kernel host. Confronta i privilegi effettivamente concessi, i dispositivi e i file esposti, l'unità che aggiorni e ripristini e le conseguenze di una fuga dal confinamento. Se l'esposizione a un kernel condiviso è di per sé inaccettabile, smetti di confrontare Docker e LXC e usa una VM o un host separato.

Accetta il confine del kernel condiviso prima di confrontare le funzionalità

Docker normalmente raggruppa un'applicazione e le sue dipendenze; LXC offre uno userspace Linux più completo, con init, account, pacchetti e servizi di sistema. Questa differenza operativa non fornisce a LXC un kernel guest indipendente.

Le ricerche sul confinamento dei container Linux descrivono i meccanismi basati su namespace e policy come un insieme eterogeneo, la cui semantica può essere difficile da verificare. Questo limite del confinamento basato su un kernel condiviso si applica a entrambe le opzioni e impedisce a ciascuna di diventare la risposta quando la separazione del kernel è obbligatoria.

Mantieni entrambe le opzioni in considerazione solo per carichi di lavoro affidabili o circoscritti. Sposta il codice esposto a Internet, le immagini sconosciute o l'automazione ad alto impatto in una VM quando una compromissione non deve raggiungere direttamente il kernel host.

Lascia che il privilegio richiesto cambi la scelta predefinita

Docker rimane interessante quando il servizio necessita di poche capability esplicite, configurazioni in sola lettura e uno o due percorsi persistenti. La sua definizione Compose può rendere visibili queste eccezioni durante la revisione.

LXC è adatto ai servizi che si aspettano un sistema Linux convenzionale, diversi demoni, un gestore di pacchetti o una rete stabile a livello di sistema. LXC non privilegiato conserva un'utile mappatura degli UID, ma la modalità privilegiata, il nesting e i bind mount estesi ne riducono il vantaggio.

Conta le eccezioni invece di selezionare una casella per i privilegi. Se uno dei due progetti richiede la rete dell'host, il socket di gestione dei container, mount di sistema scrivibili, l'accesso a ogni dispositivo o un profilo non confinato, riprogetta il percorso di accesso oppure abbandona il livello basato sul kernel condiviso.

L'accesso ai dispositivi e allo storage determina il raggio d'impatto

Un coordinatore USB, un nodo di rendering GPU, un'interfaccia UPS o una directory multimediale dovrebbero essere esposti nel modo più limitato consentito dal servizio. Percorsi stabili per i dispositivi, mount in sola lettura e proprietà UID/GID esplicite sono controlli di contenimento oltre che impostazioni pratiche.

Un resoconto recente di una distribuzione Proxmox mostra che LXC non privilegiato può isolare i servizi basati su Docker in unità di ripristino separate, condividendo comunque il kernel host e lo stack di storage. Questo modello LXC a basso raggio d'impatto è utile solo quando il nesting e le eccezioni dei driver di storage rimangono documentati.

Preferisci Docker quando una singola app necessita di un unico piccolo confine dati. Preferisci LXC quando diversi servizi di sistema devono appartenere allo stesso ambiente. Rifiuta entrambe le architetture se una sola compromissione consente l'accesso in scrittura ai backup, al controllo dell'hypervisor o ai dati personali non correlati.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Confronta l'unità che aggiorni e ripristini

Il rollback di Docker normalmente consiste nel ripristinare la revisione Compose e l'immagine precedenti, insieme ai dati coerenti con l'applicazione. Il rollback di LXC può ripristinare un intero userspace, il che è comodo, ma può anche riattivare pacchetti obsoleti, credenziali e modifiche manuali nascoste.

Ricostruisci ciascuna opzione su un host usa e getta. Per Docker, ripristina definizioni, segreti e volumi; per LXC, ricrea o ripristina il container e verifica lo stato di pacchetti, rete, dispositivi e mount. Un test riuscito e ripetibile offre prove più solide rispetto a un consumo inferiore di memoria a riposo.

La decisione più ampia di ZimaSpace sui confini dei servizi tra VM, LXC e Docker è il passaggio successivo quando resta in considerazione un kernel indipendente.

Verdetto condizionale: scegli il confine più ristretto che contenga comunque il guasto

Scegli Docker per un'unica applicazione affidabile e ben impacchettata, i cui dispositivi, capability, segreti e percorsi persistenti possano rimanere espliciti e ridotti al minimo.

Scegli LXC per un ambiente di servizi Linux affidabile che tragga davvero vantaggio da init, pacchetti, più demoni o dalla rete a livello di sistema, mantenendolo non privilegiato ove possibile.

Non scegliere nessuna delle due opzioni quando il carico di lavoro necessita di un ampio controllo sull'host, gestisce input ostili con conseguenze rilevanti o deve resistere alla compromissione del kernel host. A quel punto una VM o una macchina separata non è sovraingegnerizzazione: è il confine di sicurezza mancante.