In esecuzione shred su un file in memoria è inutile. È probabile che i dati del file siano presenti anche nella memoria dell'applicazione, nelle cache, ecc. La memoria che apparteneva a un processo non viene cancellata quando il processo muore:Linux, come la maggior parte dei kernel, cancella la memoria prima di concederla a un processo, non al rilascio, perché è più veloce.
Naturalmente, non c'è alcuna garanzia che il file può essere recuperato. Ma non c'è alcuna garanzia che non possa farlo. Se il tuo modello di attaccante è che l'attaccante può vedere il tuo contenuto RAM, c'è molto di cui devi occuparti. Per lo meno è necessario cancellare le pagine RAM non appena vengono rilasciate dal processo. Puoi applicare le patch Grsecurity al kernel Linux, almeno le PAX_MEMORY_SANITIZE opzione. E devi stare attento a quali processi sono in esecuzione e potrebbero archiviare informazioni riservate. E tieni presente che il kernel memorizza anche informazioni riservate, come lo stato RNG e le chiavi di crittografia del disco. La patch TRESOR al kernel Linux protegge le chiavi di crittografia del disco durante il normale funzionamento, ma non è una difesa perfetta e non conosco 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 (es. ext3, ext4, reiserfs).
Supponendo che tu non stia usando nessun unionfs per la persistenza (apparentemente puoi farlo in Tails anche se non ci ho mai provato), tutto è memorizzato in un tmpfs .
La documentazione di Linux su tmpfs non specifica se esegue il journaling. Eppure, tmpfs è basato su ramfs , lo stesso filesystem utilizzato in initramfs e quel filesystem non ha un journal. Pertanto è (più o meno) sicuro supporre che tmpfs non ha nemmeno un diario.
Su un filesystem senza un journal shred eseguirà la sovrascrittura del file, rendendo difficile il ripristino con strumenti analitici (praticamente impossibile il ripristino da un dump della RAM). Poiché tutto accade nelle pagine di memoria e negli inode di un tmpfs basta puntare alle pagine di memoria, usando shred è molto meglio perché sarà in grado di scrivere su queste pagine di memoria.
Avvertenza
Quanto sopra funziona sicuramente in questo modo su Tails e su Knoppix. Probabilmente funzionerà in modo simile su quasi tutte le distribuzioni Linux su LiveCD, incluso Kali Linux, ma c'è un avvertimento .
Questo funziona per i file! La memoria conterrà anche la memoria dell'applicazione, vedere la risposta di Gilles sulla memoria dell'applicazione. Seriamente, guarda quella risposta, apre un punto importante.
Anche una distro basata su Ubuntu Linux (che può includere o meno Kali Linux* poiché il suo predecessore, Backtrack, era basato su Ubuntu) monterà qualsiasi swap che trova sulla macchina che avvia, il che potrebbe 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 postgres database da usare con metasploit . Postgres ha il suo journaling (che è basato su file e non su filesystem), che potresti voler distruggere anche tu (cioè distruggere i file postgres non solo eliminare i dati tramite psql ).
* Kali non è basato su Ubuntu, è basato su Debian, ma non sono sicuro che abbia abbandonato tutti i suoi script di configurazione dal momento in cui si chiamava Backtrack ed era basato su Ubuntu