In che modo un bind mount modifica la sicurezza del container su un server domestico?

Un bind mount cambia la sicurezza del container dando a un processo interno accesso diretto a un percorso reale sul server domestico. Questo accesso bypassa parte del confine del filesystem usa e getta del container e rende i file dell'host, le regole di proprietà, le etichette e le opzioni di mount parte del modello di sicurezza del container.

Il mount non è automaticamente insicuro. Il rischio dipende da quale percorso dell'host è esposto, se il container può scriverci, quale utente esegue il processo e se sono inclusi percorsi sensibili come il socket Docker, directory di configurazione o cartelle di backup.

Quale confine attraversa un bind mount?

Un container normalmente vede il proprio filesystem a strati e volumi gestiti selezionati. Un bind mount espone un percorso reale dell'host, quindi i file creati o modificati tramite quel percorso sono modifiche al filesystem dell'host.

Il container usa ancora namespace e kernel dell'host, ma la directory montata non è più isolata dietro il layer scrivibile dell'immagine. L'applicazione può interagire con gli stessi file che i servizi host, gli strumenti di backup o altri container possono usare.

Questo cambia la domanda di sicurezza da 'Cosa c'è dentro l'immagine?' a 'Quali oggetti dell'host può raggiungere questo processo?' Una piccola directory media e il filesystem root del server creano esposizioni molto diverse anche quando l'immagine del container è identica.

Perché l'accesso scrivibile amplia il raggio d'azione del danno?

I bind mount sono comunemente scrivibili a meno che non siano configurati diversamente. Un mount scrivibile significa che i processi del container possono modificare i file dell'host usando i permessi disponibili al processo del container.

Un media server compromesso potrebbe quindi criptare una libreria montata, modificare la configurazione, sostituire script o cancellare file che altrimenti sopravviverebbero alla rimozione del container. Il danno persiste perché i dati risiedono al di fuori del layer del container.

Snapshot e backup possono ancora aiutare, ma devono contenere uno stato precedente integro. gli snapshot possono preservare dati già corrotti, quindi il design del mount dovrebbe limitare i danni prima che sia necessaria la cronologia delle versioni.

Come riducono il rischio le mount in sola lettura?

Un bind mount di sola lettura preserva la visibilità dell’host bloccando le scritture normali attraverso quel mount. Per configurazioni, input multimediali, certificati o dati di riferimento, i mount di sola lettura limitano le modifiche al filesystem senza nascondere i file di cui l’applicazione ha bisogno.

La modalità di sola lettura riduce fortemente il raggio d’azione di un attacco, ma non è un isolamento completo. Il container può comunque leggere segreti, file personali, metadati o credenziali se il percorso montato è troppo ampio.

Le applicazioni hanno anche bisogno di posizioni scrivibili esplicite per database, upload, cache o log. Montare solo quelle directory ristrette come scrivibili è più sicuro che esporre un intero albero applicativo o la home directory dell’utente.

Perché UID, GID e le etichette sono ancora importanti?

Un bind mount mantiene la proprietà e le regole di accesso del filesystem dell’host. Il processo del container non acquisisce permessi astratti di volume; i mount di volume possono rivelare informazioni dell’host attraverso il mapping esatto di percorso e identità fornito.

Quando la root del container mappa direttamente alla root dell’host, un percorso scrivibile può essere particolarmente pericoloso. Eseguire l’applicazione con un UID non root limita l’accesso, ma valori UID e GID non corrispondenti possono anche creare errori di permessi che gli utenti a volte “risolvono” con impostazioni chmod troppo ampie.

SELinux o un altro sistema di controllo accessi obbligatorio aggiunge una seconda decisione oltre ai bit di modalità Unix. Etichette corrette possono confinare il container anche quando la proprietà numerica sembra permettere l’accesso, mentre disabilitare l’etichettatura può rimuovere questa protezione.

Perché alcuni percorsi dell’host sono molto più pericolosi?

Il rischio è determinato dalle capacità, non solo dal numero di file. Montare il socket Docker espone il controllo del daemon e può permettere a un container compromesso di creare container privilegiati o montare ulteriori percorsi dell’host.

Montare la root del server, `/etc`, le chiavi SSH, la configurazione dei pacchetti o i segreti delle applicazioni può trasformare una compromissione del container in un accesso più ampio all’host. Un mount contenente script eseguibili può anche diventare un percorso di persistenza se un altro processo dell’host esegue quei file.

I normali percorsi dei dati possono comunque essere sensibili. Foto di famiglia, esportazioni di gestori di password, documenti fiscali e backup potrebbero non aiutare un attaccante a uscire dal container, ma la lettura o la cancellazione non autorizzata rappresenta già una grave falla di sicurezza.

Come dovrebbe un server domestico gestire i bind mount?

Iniziare con la directory host più piccola che soddisfa l'applicazione. i namespace di mount isolano le viste del filesystem, e ogni bind mount dovrebbe essere trattato come un'eccezione intenzionale a quella vista.

Preferire l'accesso in sola lettura per gli input, eseguire il container come utente non root dedicato, mantenere i segreti fuori da mount di dati ampi e evitare socket o directory di sistema a meno che l'applicazione non li richieda davvero.

Verificare il percorso effettivo dopo l'applicazione di symlink, permessi ed etichette. Un design sicuro dovrebbe fare in modo che la rimozione o la compromissione di un container influenzi solo il proprio ristretto confine dati, mentre backup indipendenti preservano un altro confine di recupero.

FAQ

Un bind mount è meno sicuro di un volume Docker?

Non automaticamente. Un bind mount espone direttamente un percorso host scelto, mentre un volume gestito è più astratto. La sicurezza dipende dall'ambito del percorso, dall'accesso in scrittura, dall'identità del processo e dalle etichette.

La modalità sola lettura rende sicuro un mount sensibile?

Impedisce la modifica normale tramite quel mount, ma il container può comunque leggere tutto ciò che il percorso espone. Segreti e file privati non dovrebbero essere montati a meno che non sia necessario.

Un container non root può danneggiare i file montati con bind?

Sì, quando il suo UID o i gruppi hanno permessi di scrittura sul percorso host. L'uso di un utente non root riduce i privilegi ma non sovrascrive le regole effettive di proprietà e accesso.

Perché montare il socket Docker è pericoloso?

Il socket controlla il demone Docker. L'accesso può permettere a un container di avviare carichi di lavoro privilegiati, ispezionare segreti o montare directory aggiuntive dell'host.

Conclusione finale

Un bind mount è un'apertura intenzionale attraverso il confine del filesystem del container. La sua sicurezza dipende dalla capacità esposta dal percorso host: dati in sola lettura, stato dell'applicazione scrivibile, segreti sensibili o controllo amministrativo. Percorsi ristretti, impostazioni predefinite in sola lettura, identità non root, etichette corrette e backup indipendenti impediscono che un container diventi un punto di fallimento per l'intero server domestico.