Container Docker vs LXC dedicato per i servizi domestici privilegiati: quale comporta più rischi?
Scegli un container Docker con il minimo privilegio quando il servizio è distribuito come immagine e richiede solo file, porte, dispositivi e funzionalità mappati in modo circoscritto. Scegli un LXC non privilegiato dedicato quando il servizio richiede un ambiente Linux più completo, un'integrazione diretta con il sistema o diversi processi correlati all'interno di un guest gestito separatamente. Nessuno dei due modelli rimane un confine di sicurezza significativo dopo aver esposto ampie directory dell'host, il socket Docker, dispositivi senza restrizioni o privilegi root a livello di host.
Confronta prima confini di distribuzione equivalenti
Docker e LXC sono entrambe tecnologie di container Linux che condividono il kernel dell'host, ma normalmente pacchettizzano unità diverse. Docker isola di norma una singola applicazione o uno stack Compose. LXC crea un container di sistema leggero con i propri utenti, il database dei pacchetti, i servizi e il filesystem del sistema operativo.
Il confronto corretto è quindi tra un'applicazione Docker eseguita direttamente su un host Linux e lo stesso servizio domestico privilegiato installato all'interno di un LXC dedicato. Non si tratta del confronto tra Docker dentro LXC e LXC in sé, né del confronto tra uno dei due modelli di container e una macchina virtuale con un kernel separato.
Il confronto ZimaSpace esistente tra Docker e installazioni native all'interno di LXC tratta il pacchettizzamento e la manutenzione. Questo articolo isola la decisione relativa alla sicurezza quando il servizio richiede privilegi che indeboliscono i normali confini dei container.
| Aspetto della sicurezza | Container Docker dell'applicazione | Container di sistema LXC dedicato |
|---|---|---|
| Unità di isolamento principale | Processo dell'applicazione e relative dipendenze pacchettizzate | Spazio utente Linux con più servizi e utenti |
| Kernel dell'host | Condiviso con l'host | Condiviso con l'host |
| Mappatura dell'utente root | Privilegiato per impostazione predefinita, a meno che non vengano usati gli user namespace o la modalità rootless | Può essere privilegiato oppure mappare l'utente root del container a un UID non privilegiato dell'host |
| Accesso ai dispositivi | È possibile mappare singoli dispositivi; la modalità privilegiata li espone in modo esteso | I nodi dei dispositivi e le autorizzazioni dell'host possono essere mappati nel guest |
| File dell'host | I bind mount espongono direttamente all'app i percorsi selezionati dell'host | I bind mount espongono i percorsi al guest e a ogni processo autorizzato al suo interno |
| API amministrativa | Il socket Docker può consentire il controllo dell'host Docker | Nessun socket daemon equivalente, a meno che non venga installato un altro runtime all'interno di LXC |
| Scelta migliore | Applicazione pacchettizzata con privilegi rigorosamente limitati | Servizio che richiede l'integrazione con il sistema operativo all'interno di un ambiente guest non privilegiato |
Inizia con i privilegi esatti richiesti dal servizio
“Servizio domestico privilegiato” può indicare diversi permessi non correlati: leggere un dispositivo seriale USB, utilizzare un nodo di rendering GPU, controllare un’interfaccia di rete, montare un filesystem, collegarsi a una porta inferiore a 1024, accedere al Bluetooth, leggere i dati SMART o gestire altri container. Questi permessi non comportano lo stesso livello di rischio per l’host.
Concedi la capability, il dispositivo, il percorso e la modalità di rete minimi necessari per far funzionare il servizio. La spiegazione di Snyk sulla modalità privilegiata del container sottolinea che l’accesso privilegiato completo espone tutti i dispositivi dell’host e poteri quasi equivalenti a quelli dell’host. Non dovrebbe sostituire l’analisi dell’unico permesso mancante.
Se un servizio ha bisogno soltanto di /dev/dri/renderD128, un percorso seriale identificato dall’ID o una directory di configurazione di sola lettura, sia Docker sia LXC possono esporre quella risorsa circoscritta. La differenza in termini di sicurezza diventa significativa quando la distribuzione richiede capability estese o l’accesso a più superfici dell’host.
LXC non privilegiato crea un confine più solido per il mapping di root
In un LXC non privilegiato, l’UID 0 all’interno del guest viene mappato su un normale UID subordinato dell’host Proxmox. Un processo può apparire come root all’interno del container, pur non possedendo l’identità di root dell’host al di fuori del proprio spazio dei nomi degli utenti. Questo riduce le conseguenze di molti errori nei permessi dei file e di alcune evasioni dal container.
Il progetto Linux Containers descrive il mapping di root di LXC non privilegiato come il principale confine di sicurezza del design, con AppArmor, seccomp e le capability che aggiungono ulteriori restrizioni sui processi e sulle risorse dell’host.
Il vantaggio dipende dal mantenimento del container in modalità non privilegiata. Un LXC privilegiato non utilizza lo stesso rimappamento degli UID, quindi root all’interno del guest corrisponde molto più direttamente a root sull’host. Convertire il container in modalità privilegiata solo per semplificare i mount o i dispositivi può eliminare il motivo per cui LXC sembrava più sicuro.
Docker può ridurre il rischio legato a root senza spostare l’app in LXC
I container Docker non devono necessariamente essere eseguiti con un demone rootful senza restrizioni e un’applicazione che usa l’utente root. Un’immagine del container può specificare un utente non root, il runtime può rimuovere le capability, i filesystem possono essere di sola lettura e gli spazi dei nomi degli utenti possono rimappare le identità del container.
La modalità rootless di Docker esegue sia il demone sia i container senza privilegi di root sull’host. Ciò può ridurre i rischi legati al demone e al runtime quando l’applicazione e le funzionalità di archiviazione o di rete richieste supportano le limitazioni della modalità rootless.
Docker rimane il confine migliore quando l’app è già ben pacchettizzata e necessita soltanto di un privilegio definito e circoscritto. Spostarla in un LXC completo aggiunge un altro sistema operativo da aggiornare senza ridurre automaticamente la risorsa mappata disponibile per l’applicazione compromessa.
Il socket Docker può annullare il confine dell’applicazione
Alcune dashboard, applicazioni per gli aggiornamenti automatici, strumenti di backup e servizi di monitoraggio richiedono l’accesso a /var/run/docker.sock. Il socket consente a un client di istruire il demone Docker dell’host a creare container, montare percorsi dell’host, esporre dispositivi e modificare le reti. Un servizio compromesso può quindi controllare indirettamente l’host senza sfruttare un’evasione dal kernel.
L’analisi di Netdata spiega perché l’accesso al socket Docker equivale all’amministrazione dell’host: il processo chiede al demone privilegiato di Docker di eseguire potenti azioni sull’host per suo conto, senza una tradizionale evasione dal container.
Questo è il primo limite da considerare. Se il servizio richiede un accesso illimitato al socket Docker, confrontare il normale isolamento di Docker con quello di LXC è fuorviante. Considerate il servizio come un amministratore dell’host, limitatene l’API tramite un proxy dedicato, se possibile, isolatelo dalle reti non attendibili e proteggetene adeguatamente le credenziali.
La mappatura dei dispositivi favorisce il modello con meno livelli di autorizzazione
È possibile assegnare a entrambi i deployment una GPU, un coordinatore USB, un sintonizzatore, un acceleratore Coral, un UPS o un adattatore seriale. Con Docker diretto, l’host espone il dispositivo al container dell’applicazione. Con LXC, Proxmox espone il dispositivo al container di sistema, che poi esegue il servizio in modo nativo oppure può inoltrarlo nuovamente a Docker annidato.
L’LXC dedicato può essere più pulito quando diversi processi correlati devono usare lo stesso dispositivo e l’accesso deve essere gestito dagli utenti o dai gruppi Linux. Docker può essere più pulito quando un’unica immagine necessita di un solo dispositivo e la mappatura è descritta direttamente in Compose.
Evita di concedere a entrambi i container l’accesso a tutti i dispositivi solo perché l’autorizzazione per un singolo dispositivo è difficile. Proxmox osserva che la sicurezza LXC combina namespace, AppArmor, seccomp e restrizioni sui dispositivi. Un accesso esteso ai dispositivi elimina parte di questo confine stratificato, proprio come fa la modalità privilegiata di Docker.
I bind mount dell’host trasferiscono il rischio in direzioni diverse
Un bind mount Docker espone direttamente all’applicazione il percorso host selezionato. Un mount scrivibile contenente foto, backup, configurazione o lo stato di altre applicazioni concede a un container compromesso gli stessi diritti di modifica dell’utente host mappato su quel percorso.
Un bind mount LXC espone il percorso al guest, dove più servizi e utenti amministrativi possono accedervi in base alle mappature UID e GID. Il confine aggiuntivo del sistema può aiutare a organizzare i permessi, ma amplia anche l’insieme dei processi all’interno del guest che potrebbero raggiungere i dati.
Usa mount in sola lettura quando possibile, separa la configurazione dai dati voluminosi ed evita di mappare la root dell’host, /proc, /sys, /dev, o alle directory dei dati Docker in modo esteso. Se il servizio deve riscrivere dati protetti sul NAS, l’isolamento dell’applicazione non può sostituire gli snapshot e i backup indipendenti.
I privilegi di rete possono creare un raggio d’impatto più ampio rispetto all’accesso al filesystem
Servizi domestici come gateway VPN, filtri DNS, strumenti di rilevamento della rete, integrazioni con Home Assistant e sistemi di monitoraggio possono richiedere la rete dell’host, socket raw, cattura dei pacchetti, modifica del firewall o accesso a diverse VLAN. Queste funzionalità possono esporre il traffico e consentire al servizio di influenzare altri dispositivi.
Un container Docker con rete dell’host perde la separazione di rete a livello di porta, mentre funzionalità aggiuntive come NET_ADMIN oppure NET_RAW aumentare ciò che una compromissione può fare. Un LXC con una propria interfaccia virtuale può fornire un indirizzo separato e una policy firewall distinta, ma un guest privilegiato o collegato a bridge in modo esteso può comunque raggiungere reti sensibili.
Scegli il confine che ti consente di definire il percorso di rete più ristretto. Una VLAN separata, un indirizzo dedicato, regole firewall esplicite e nessun accesso alla gestione del NAS spesso riducono il rischio più del passaggio a un’altra tecnologia per container, lasciando però il servizio su ogni rete considerata attendibile.
LXC privilegiato e Docker privilegiato falliscono in modi diversi
Un container Docker completamente privilegiato riceve ampie funzionalità Linux e l’accesso ai dispositivi tramite un demone Docker eseguito con privilegi root. Un LXC privilegiato offre a uno spazio utente guest completo una relazione molto più simile a quella dell’utente root dell’host. Nessuno dei due dovrebbe essere trattato come un normale container applicativo senza privilegi.
Le linee guida sulla sicurezza di Tigera avvertono che la modalità Docker privilegiata aggira importanti controlli di isolamento. Anche le discussioni della community di Proxmox avvertono che abilitare il nesting o un accesso troppo ampio al filesystem dell’host all’interno di LXC può esporre le superfici /proc e /sys dell’host se configurato senza attenzione.
Se il servizio richiede realmente poteri equivalenti a quelli di root sull’host, una VM con un kernel dedicato può offrire un confine di contenimento più chiaro. Il maggiore consumo di memoria e spazio di archiviazione può essere giustificato quando il servizio è esposto a Internet, elabora input non attendibili, carica driver adiacenti al kernel o amministra altri carichi di lavoro.
Gli aggiornamenti e il ripristino determinano se l’isolamento resta utilizzabile
Docker rende sostituibile il pacchetto dell’applicazione. Ricrea il container da un’immagine o da un digest bloccato, ripristina la configurazione e i dati persistenti, quindi riapplica gli stessi privilegi ristretti. Questo è utile quando la policy di sicurezza è visibile in Compose anziché ricordata da comandi shell.
Un LXC dedicato rende sostituibile l’ambiente operativo come un unico guest Proxmox. Il database dei pacchetti, i file dei servizi, gli utenti e le mappature dei dispositivi possono essere sottoposti a backup insieme. Il ripristino è ordinato quando i bind mount, le mappature UID, i dispositivi dell’host e le regole di rete sono documentati al di fuori del guest.
Il confronto di ZimaSpace tra i confini di ripristino di una Docker VM e di un LXC per app offre il test operativo complementare. Un confine di sicurezza più ristretto è utile solo se può essere ripristinato senza ricreare manualmente privilegi troppo ampi.
Esegui un test di riduzione dei privilegi prima di scegliere Docker o LXC
- Elenca ogni dispositivo, percorso dell’host, capability, rete, API e funzionalità del kernel richiesti dal servizio.
- Rimuovi la modalità completamente privilegiata e riaggiungi un requisito alla volta.
- Esegui l’applicazione come utente non root oppure all’interno di un LXC non privilegiato, quando supportato.
- Sostituisci i mount scrivibili troppo ampi con percorsi ristretti di sola lettura o specifici per dataset.
- Rimuovi l’accesso al socket Docker oppure inserisci un proxy con accesso limitato tra il servizio e il demone.
- Verifica le ipotesi di compromissione controllando quali file, dispositivi e reti dell’host restano raggiungibili.
- Ripristina il servizio su un host Docker o LXC pulito utilizzando solo una configurazione con versioni specificate.
Non valutare la sicurezza solo in base al numero di livelli. Valuta le autorizzazioni effettive disponibili dopo aver aggiunto tutti i dispositivi, mount, capability, socket e reti necessari. Un container semplice con accesso ristretto può essere più sicuro di una progettazione annidata complessa con diverse eccezioni.
Quale confine è adatto a un servizio domestico privilegiato?
Quando scegliere un container Docker per un'app
Scegli Docker quando il servizio è distribuito come immagine, necessita di uno o due dispositivi o mount espliciti e può funzionare senza --privileged, accesso senza restrizioni al socket Docker o ampio networking dell'host. Blocca le versioni, rimuovi le capability, usa filesystem in sola lettura quando possibile e mantieni espliciti i dati persistenti.
Quando scegliere un LXC non privilegiato dedicato
Scegli LXC quando il servizio necessita di un ambiente Linux più completo, di diversi demoni correlati, dell'integrazione diretta con systemd o di autorizzazioni complesse per i gruppi di dispositivi. Mantieni la mappatura dello user namespace, conserva le restrizioni di AppArmor e seccomp e documenta ogni mount dell'host e ogni mappatura dei dispositivi.
Quando scegliere invece una VM
Usa una VM quando il carico di lavoro necessita di un controllo equivalente al root dell'host, carica driver insoliti, amministra altri carichi di lavoro, accetta input pubblici non attendibili o non può funzionare senza ampi privilegi sul filesystem e sulla rete. Un kernel separato crea un confine più solido rispetto all'aggiunta di altre eccezioni a un container che condivide il kernel.
Domande frequenti
Un LXC privilegiato è più sicuro di un container Docker privilegiato?
Non come regola generale. Entrambi hanno indebolito importanti controlli di isolamento, ma espongono i privilegi in modo diverso. Valuta la mappatura degli UID, i dispositivi, i mount, le capability, l'accesso di rete, AppArmor, seccomp e le API del demone, invece di basarti sull'etichetta del container.
Eseguire Docker all'interno di un LXC non privilegiato aggiunge un ulteriore livello di sicurezza?
Può aggiungere la mappatura degli UID tra l'LXC e l'host Proxmox, ma Docker annidato potrebbe richiedere funzionalità di nesting, capability aggiuntive, eccezioni al filesystem o mappature dei dispositivi. Queste modifiche possono annullarne i vantaggi. Una VM è più chiara quando è necessaria una forte separazione dall'host.
I servizi domestici accessibili solo dalla LAN hanno bisogno di container non privilegiati?
Sì, quando la compromissione può arrivare da un altro dispositivo della LAN, da un'interfaccia web vulnerabile, da contenuti multimediali o documenti malevoli, da immagini della catena di fornitura o da credenziali esposte. Collocare il servizio solo nella LAN riduce parte dell'esposizione, ma non rende innocuo l'accesso root all'host.
Verdetto finale
Usa Docker quando un'applicazione pacchettizzata può funzionare con privilegi dichiarati in modo restrittivo e senza interfacce amministrative dell'host. Usa un LXC non privilegiato quando un servizio necessita di un sistema Linux più completo, mantenendo al contempo la mappatura di root e un accesso controllato ai dispositivi. Se uno dei due approcci richiede ampi privilegi di root sull'host, socket senza restrizioni o accesso in scrittura a dati critici, interrompi il confronto tra container e sposta il servizio dietro il confine più solido di una VM o di una macchina separata.
Prodotti consigliati
Confronti tra prodotti
Altro da leggere
Server WireGuard vs VPN mesh per dispositivi dietro CGNAT
Usa una VPN mesh per dispositivi in roaming senza complicazioni; usa un relay WireGuard quando vuoi gestire in autonomia il routing, le chiavi e...
NAS 10GbE su client Gigabit: conviene aggiornare prima il server o gli endpoint?
Potenzia il percorso endpoint per una workstation lenta; potenzia prima l'uplink del NAS quando diversi client gigabit lo saturano insieme.
1GbE vs 2.5GbE per un server domestico: quali carichi di lavoro fanno la differenza?
Mantieni 1GbE per servizi leggeri e flussi singoli; passa a 2,5GbE quando i trasferimenti ricorrenti o i client combinati superano stabilmente circa 100 MB/s.
