Elimina in modo sicuro i file sul filesystem btrfs

22

A volte, è necessario eliminare un file in un filesystem e assicurarsi che il file sia veramente sparito. Un file che contiene password sensibili, ad esempio, dovrebbe essere cancellato dal disco.

L'emissione di un semplice rmsu un tipico file system cancella l'inode ("puntatore") sul file, ma non elimina il contenuto del file nel disco fisico - questi vengono lasciati lì fino a quando non vengono sovrascritti quando il filesystem necessita dello spazio libero.

Su molti file system, il programma shred consente tale cancellazione sicura. Tuttavia, su un filesystem CoW come btrfs, questo approccio è inutile . Il problema è aggravato dal fatto che il file potrebbe essere presente nelle istantanee del volume.

C'è un modo per eliminare in modo sicuro un file su un filesystem btrfs? È sufficiente eliminare tutti i puntatori (su tutti i volumi) e riempire lo spazio libero con zeri ?

— goncalopp
fonte

2

Bella domanda, non ho mai pensato a questo problema prima. Un modo per aggirare il problema sarebbe crittografare tali file. Puoi anche crittografare l'intero disco, ma se un utente malintenzionato ottiene l'accesso root al sistema in esecuzione, ciò non ti aiuterà ...

— mreithub,

@mreithub In effetti, la crittografia di tali file è sempre una buona idea in primo luogo, come lo è FDE. Tuttavia, non può contemplare tutti i casi d'uso (un sistema incorporato, ad esempio - sebbene sia discutibile se tale sistema eseguirà comunque btrfs ...). In realtà lo sto chiedendo perché ho dimenticato di impostare la crittografia prima di copiare i file sensibili, ma vorrei evitare di cancellare l'intera partizione

— goncalopp,

9

La cancellazione sicura è una proposta difficile su qualsiasi filesystem. A meno che il filesystem non sia molto particolare e garantisca che non ci siano altre copie del file in circolazione, è necessario liberare tutto lo spazio libero sul dispositivo. Mentre è più probabile trovare molti bit del file su filesystem copy-on-write, anche più filesystem “statici” non hanno questa garanzia in pratica, perché molti file vengono modificati, quindi ce ne sono alcuni dalle versioni precedenti del file in giro.

Si noti che la cancellazione con zero è buona come la cancellazione con byte casuali e non sono necessari più passaggi. La cancellazione con zero ha lasciato dati residui che potevano essere parzialmente recuperati in condizioni di laboratorio con le tecnologie del disco rigido degli anni '80; questo non è più applicabile oggi. Vedi Perché scrivere zeri (o dati casuali) su un disco rigido più volte rispetto a farlo una volta sola?

È possibile eliminare i dati riservati in chiaro crittografando tutto sul disco. Imposta un volume ecryptfs su quel file system e sposta tutti i tuoi file (riservati) su di esso. Quindi sovrascrivere tutto lo spazio inutilizzato del filesystem. Puoi cancellarne la maggior parte riempiendo il filesystem cat /dev/zero >zero. Potrebbero esserci ancora alcune informazioni lasciate in blocchi incompleti (blocchi che contengono l'ultimo blocco di un file, seguiti da un po 'di immondizia - che potrebbero essere gli avanzi di un file riservato). Per assicurarsi che non ci siano blocchi incompleti, spostare tutto sul filesystem su ecryptfs (i file di ecryptfs usano blocchi interi, almeno su configurazioni tipiche in cui i blocchi sono 4kB). Assicurati di applicarlo a tutti i volumi e di cancellare tutte le istantanee contenenti dati riservati in chiaro.

Potrebbero esserci ancora alcune informazioni nel diario. Non so come strofinarlo.

Su SSD, a causa della riallocazione del blocco, potrebbero essere rimasti dei dati che non possono essere letti con i normali software ma possono essere recuperati hackerando il firmware o con accesso fisico. La tua unica risorsa è una cancellazione completa dell'SSD.

— Gilles 'SO- smetti di essere malvagio'
fonte

3

Gli zeri hanno lo svantaggio di poter essere compressi o completamente omessi (un SSD può TRIM invece di scrivere zero, poiché i settori TRIM restituiscono zero quando li leggi). Ciò rende gli zeri non sicuri al giorno d'oggi. L'uso di dati casuali impone al file system e al disco di scrivere effettivamente i dati così come sono.

— frostschutz,

@frostschutz Scrivere un personaggio diverso da 0quello ok, e non soggetto a TRIM, direbbe invece scrivere tutto 1? O alcune unità usano la compressione su tutto?

— Xen2050,

@frostschutz Se stai riempiendo un volume di ecryptfs con zero (che è quello che pensavo fosse la risposta qui, anche se, su un'ulteriore ispezione, vedo che il suo fraseggio è in realtà ambiguo), allora scriverai essenzialmente in modo casuale (non comprimibile / uncheatable) dati sul disco, no?

— JamesTheAwesomeDude

@JamesTheAwesomeDude No, stavo proponendo di scrivere gli zeri nella parte non crittografata, ma ho detto che questo non era abbastanza su un SSD più avanti.

— Gilles 'SO- smetti di essere malvagio' il

6

Hmmm, btrfs sembra sconfiggere tutti i soliti metodi di distruzione ...

C'è un'opzione di mount chiamata nodatacowma che non sembra influenzare i file già esistenti.
Dato che hai già file sensibili sul tuo disco, questa voce FAQ di btrfs non ti aiuterà neanche.
Poi c'è debugfs. È solo per filesystem ext ma c'è una patch che potrebbe funzionare. Puoi usarlo per scoprire gli indirizzi di blocco interessati e poi sovrascriverli direttamente su / dev / sdXY. Ma è molto pericoloso e potrebbe non funzionare (specialmente se ci sono più istantanee del file)
Scrivi una patch btrfs che ti permetta di modificare (o distruggere) istantanee specifiche o un intero file
Il tentativo più pulito (per dati veramente sensibili) sarebbe:
- acquista un altro disco (a meno che tu non abbia abbastanza spazio libero per una copia della partizione interessata sul primo)
- configurare la crittografia del disco completo e i file system su di esso
- copia tutto dal disco a a b
- avviare nel sistema b e distruggere l'intero disco a ...
Questo potrebbe non essere l'approccio più economico, ma considerando i bassi costi di archiviazione di oggi e il problema che avresti con le altre opzioni, potrebbe effettivamente essere il più economico (in termini di ore di lavoro).

— mreithub
fonte

nodatacowimposta lo stato predefinito del Cflag per i file appena creati . Sicuramente si potrebbe solo chattr +C ~/.browser/logins.sqlitee poi shred?

— JamesTheAwesomeDude

-6

C'è shred(1)per Unix / Linux (dovrebbe essere nei pacchetti della tua distribuzione). Sono ciò che raccomanda il FEP .

— vonbrand
fonte

3

Se ricontrolli la domanda, vedrai che ho menzionato brandello e perché non è abbastanza per il lavoro

— goncalopp

Tutto quello che trovo sono suggerimenti per usare la crittografia di file sensibili, per il motivo che menzioni.

— vonbrand,

2

"Su molti file system, il programma shred consente tale cancellazione sicura. Tuttavia, su un file system CoW come btrfs, questo approccio è inutile.". Ci sono anche due link lì.

— goncalopp,