Live OS: cancellazione sicura dei file

L'esecuzione di shred su un file in memoria è inutile. È probabile che i dati del file siano presenti nella memoria dell'applicazione, nelle cache, ecc. Memoria appartenente a un processo non cancellato quando il processo muore: Linux, come la maggior parte dei kernel, cancella la memoria prima di assegnarla a un processo, non al momento del rilascio, perché è più veloce.

Naturalmente, non c'è alcuna garanzia che il file possa essere recuperato. Ma non c'è alcuna garanzia che non possa, neanche. Se il modello dell'attaccante è che l'utente malintenzionato può visualizzare il contenuto della RAM, è necessario occuparsi di molte cose. Per lo meno è necessario cancellare le pagine RAM non appena vengono rilasciate dal processo. Puoi applicare le patch Grsecurity al kernel Linux, almeno il PAX_MEMORY_SANITIZE opzione . E devi stare attento a quali processi sono in esecuzione e potresti memorizzare informazioni riservate. E ricorda che il kernel memorizza anche informazioni riservate, come lo stato RNG e le chiavi di crittografia del disco. La patch TRESOR al kernel di Linux protegge le chiavi di crittografia del disco durante il normale funzionamento, ma non è una difesa perfetta e io non so di una patch simile per lo stato RNG.

Il pericolo che stai cercando di mitigare è il journal del filesystem, cioè shred non è efficace sui filesystem che hanno un journal (ad es. ext3, ext4, reiserfs).

Supponendo che non usi alcun unionfs per la persistenza (a quanto pare puoi farlo in Tails anche se non l'ho mai provato), tutto è memorizzato in tmpfs .

La documentazione di Linux su tmpfs non specifica se eseguire l'inserimento nel journal. Tuttavia, tmpfs è basato su ramfs , lo stesso file system che è usato in initramfs e quel filesystem non ha un journal. Quindi è (più o meno) sicuro di supporre che tmpfs non abbia un diario.

Su un filesystem senza un journal shred eseguirà la sovrascrittura del file, rendendo difficile il recupero con strumenti di analisi (praticamente impossibile da recuperare da un dump della RAM). Poiché tutto accade nelle pagine di memoria e gli inodi di tmpfs puntano semplicemente alle pagine di memoria, usare shred è molto meglio perché sarà in grado di scrivere su queste pagine di memoria.

Caveat

Quanto sopra funziona certamente in questo modo su Tails e su Knoppix . Probabilmente funzionerà in modo simile su quasi tutte le distribuzioni Linux sui LiveCD, tra cui Kali Linux ancora c'è un avvertimento .

Funziona per i file! La memoria conterrà anche la memoria dell'applicazione, vedi la risposta Gilles 'sulla memoria dell'applicazione. Seriamente, guarda quella risposta, apre un punto importante.

Anche una distribuzione basata su Ubuntu Linux (che può includere o meno Kali Linux * dal momento che il suo predecessore, Backtrack, era basato su Ubuntu) sarà monta qualsiasi scambio che trova sulla macchina che si avvia , che può lasciare un vettore di attacco molto peggiore! Dati persistenti sul dispositivo stesso!

Un altro avvertimento con Kali Linux, è che viene fornito con metasploit e avvia il database postgres da utilizzare con metasploit . Postgres ha il suo journalling (che è basato su file non basato su file system), che potresti voler distruggere (cioè distruggere i file postgres non solo eliminare i dati attraverso psql ).

_{* Kali non è basato su Ubuntu, è basato su Debian, eppure non sono sicuro che abbia abbandonato tutti i suoi script di configurazione dal momento in cui è stato chiamato Backtrack ed era basato su Ubuntu}

Usa "shred", azzera gli inode coinvolti così non ci sono più dati reali nella RAM. Ciò previene gli attacchi coldboot e gli attacchi DMA online.