Ausführen von shred auf eine Datei im Speicher ist sinnlos. Die Daten aus der Datei sind wahrscheinlich auch im Anwendungsspeicher, in Caches usw. vorhanden. Speicher, der zu einem Prozess gehörte, wird nicht gelöscht, wenn der Prozess stirbt:Linux löscht, wie die meisten Kernel, Speicher, bevor es einem Prozess gewährt wird, nicht beim Release, weil das schneller ist.
Natürlich gibt es keine Garantie dafür, dass die Datei kann wiederhergestellt werden. Aber es gibt auch keine Garantie, dass es das nicht kann. Wenn Ihr Angreifermodell darin besteht, dass der Angreifer Ihren RAM-Inhalt sehen kann, müssen Sie sich um vieles kümmern. Zumindest müssen Sie RAM-Seiten löschen, sobald sie durch den Prozess freigegeben werden. Sie können die Grsecurity-Patches auf den Linux-Kernel anwenden, zumindest auf PAX_MEMORY_SANITIZE Möglichkeit. Und Sie müssen vorsichtig sein, welche Prozesse ausgeführt werden und möglicherweise vertrauliche Informationen speichern. Und denken Sie daran, dass der Kernel auch vertrauliche Informationen wie den RNG-Status und die Festplattenverschlüsselungsschlüssel speichert. Der TRESOR-Patch für den Linux-Kernel schützt die Festplattenverschlüsselungsschlüssel während des normalen Betriebs, aber es ist keine perfekte Verteidigung, und ich kenne keinen ähnlichen Patch für den RNG-Zustand.
Die Gefahr, die Sie zu mindern versuchen, ist das Dateisystemjournal, dh shred ist nicht wirksam auf Dateisystemen, die ein Journal haben (z. B. ext3, ext4, reiserfs).
Angenommen, Sie verwenden keine unionfs für die Persistenz (anscheinend können Sie dies in Tails tun, obwohl ich es nie versucht habe), wird alles in einem tmpfs gespeichert .
Die Linux-Dokumentation auf tmpfs gibt nicht an, ob es Journaling durchführt. Dennoch tmpfs basiert auf ramfs , dasselbe Dateisystem, das in initramfs verwendet wird , und dieses Dateisystem hat kein Journal. Daher ist es (mehr oder weniger) sicher anzunehmen, dass tmpfs hat auch kein Tagebuch.
Auf einem Dateisystem ohne Journal shred führt das Überschreiben der Datei durch, was die Wiederherstellung mit analytischen Tools erschwert (so gut wie unmöglich, aus einem RAM-Dump wiederherzustellen). Da passiert alles in Speicherseiten und den Inodes eines tmpfs Zeigen Sie einfach mit shred auf Speicherseiten ist viel besser, weil es in der Lage sein wird, auf diese Speicherseiten zu schreiben.
Vorbehalt
Das obige funktioniert auf diese Weise sicherlich auf Tails und auf Knoppix. Es wird wahrscheinlich in ähnlicher Weise auf fast allen Linux-Distributionen auf LiveCDs funktionieren, einschließlich Kali Linux, aber es gibt eine Einschränkung .
Dies funktioniert für Dateien! Speicher enthält auch Anwendungsspeicher, siehe Antwort von Gilles zum Anwendungsspeicher. Im Ernst, sieh dir diese Antwort an, sie eröffnet einen wichtigen Punkt.
Auch eine auf Ubuntu Linux basierende Distribution (die Kali Linux* enthalten kann oder nicht, da ihr Vorgänger Backtrack auf Ubuntu basierte) wird jeden Swap mounten, den sie auf dem Rechner findet, den sie bootet, was einen viel schlimmeren Angriffsvektor hinterlassen kann! Persistente Daten auf dem Gerät selbst!
Eine weitere Einschränkung bei Kali Linux ist, dass es mit metasploit geliefert wird und bootet den postgres Datenbank zur Verwendung mit metasploit . Postgres verfügt über ein eigenes Journaling (das dateibasiert und nicht dateisystembasiert ist), das Sie möglicherweise ebenfalls schreddern möchten (d. h. die Postgres-Dateien schreddern und nicht nur die Daten durch psql löschen ).
* Kali basiert nicht auf Ubuntu, es basiert auf Debian, aber ich bin mir nicht sicher, ob es alle seine Konfigurationsskripte seit der Zeit, als es Backtrack hieß, fallen ließ und auf Ubuntu basierte