Shred: Funktioniert nicht mit Journaled FS?

Question

Shred Dokumentation sagt Shred ist "nicht garantiert, um effektiv zu sein" (Siehe unten). Also, wenn ich ein Dokument auf meinem Ext3-Dateisystem oder auf einem Raid shredde, was passiert? Schneide ich Teile der Datei? Zerbricht es manchmal die ganze Sache und manchmal nicht? Kann es andere Sachen zerstören? Kopiert es nur den Dateikopf?

ACHTUNG: Beachten Sie, dass shred auf einer sehr wichtigen Annahme beruht: dass das Dateisystem Daten an Ort und Stelle überschreibt. Dies ist die traditionelle Art, Dinge zu tun, aber viele moderne Dateisystem-Designs erfüllen diese Annahme nicht. Die folgenden sind Beispiele von Datei Systeme, auf denen zerkleinern nicht wirksam ist, oder nicht in allen Datei Sys- tem Modi sein wirksam garantiert:

• protokollstrukturierte oder Systeme Journaled File, wie sie geliefert mit AIX und Solaris (und JFS, ReiserFS, XFS, Ext3, etc.)

• Dateisysteme, die redundante Daten schreiben und weitermachen, auch wenn einige schreibt ausfallen, wie RAID-basierte Dateisysteme

• Datei Systeme, die Snapshots erstellen, z. B. Netzwerkgeräte NFS-Server

• Dateisysteme, die in temporären Orten zwischenspeichern, wie NFS Version 3 Clients

• komprimierte Dateisysteme

Im Fall von ext3-Dateisysteme, die oben Haftungsausschluss gilt (und Shred ist somit von begrenzter Wirksamkeit) nur in Daten = Journal Modus, der Dateidaten zusätzlich zu nur Metadaten erfasst. In sowohl die Daten = bestellt (Standard) und Daten = Writeback-Modi, Shred funktioniert wie gewohnt. Ext3 Journaling-Modi können geändert werden, indem die Option Data = etwas zu den Mount-Optionen für ein bestimmtes Dateisystem in der Datei/etc/fstab hinzugefügt wird, wie in der Mount-Manpage (man mount) dokumentiert.

Answer 1

Alle Shred Does überschreiben, spülen, den Erfolg überprüfen und wiederholen. Es ist absolut nichts, um herauszufinden, ob das Überschreiben einer Datei tatsächlich dazu führt, dass die Blöcke überschrieben werden, die die ursprünglichen Daten enthalten. Dies liegt daran, dass es keine nicht-standardmäßigen Dinge über das zugrunde liegende Dateisystem wissen kann.

Daher werden Journaling-Dateisysteme die ursprünglichen Blöcke nicht an Ort und Stelle überschreiben, da dies verhindern würde, dass sie sauber von Fehlern wiederhergestellt werden, bei denen die Änderung zur Hälfte geschrieben wurde. Wenn Daten aufgezeichnet werden, wird jeder Shred-Durchlauf möglicherweise an einen neuen Speicherort auf der Festplatte geschrieben. In diesem Fall wird nichts geschreddert.

RAID-Dateisysteme (abhängig vom RAID-Modus) überschreiben möglicherweise nicht alle Kopien der ursprünglichen Blöcke. Wenn es Redundanz gibt, könnten Sie eine Festplatte, aber nicht die andere (n) shreddern, oder Sie könnten feststellen, dass verschiedene Durchgänge unterschiedliche Festplatten betroffen haben, so dass jede Festplatte teilweise geschreddert wird.

Auf jedem Dateisystem kann die Festplatten-Hardware selbst so einen Fehler entdecken (oder im Falle von Flash Wear-Leveling auch ohne einen Fehler anwenden) und den logischen Block auf einen anderen physischen Block, wie z dass das Original als fehlerhaft (oder unbenutzt) markiert, aber nie überschrieben wird.

Komprimierte Dateisysteme überschreiben möglicherweise nicht die ursprünglichen Blöcke, da die Daten, mit denen shred überschreibt, bei jedem Durchlauf entweder zufällig oder extrem komprimierbar sind. Beides kann dazu führen, dass die Datei ihre komprimierte Größe radikal ändert und daher verschoben wird. NTFS speichert kleine Dateien in der MFT, und wenn Shred die Dateigröße auf ein Vielfaches von einem Block aufrundet, wird das erste "Überschreiben" typischerweise dazu führen, dass die Datei an einen neuen Ort verschoben wird, der dann sinnlos zerfetzt wird MFT-Steckplatz unberührt.

Shred kann keine dieser Bedingungen erkennen (es sei denn, Sie haben eine spezielle Implementierung, die direkt Ihren fs und Blocktreiber adressiert - ich weiß nicht, ob solche Dinge tatsächlich existieren). Deshalb ist es zuverlässiger, wenn es auf einer ganzen Festplatte als auf einem Dateisystem verwendet wird.

Shred vernichtet niemals "andere Sachen" im Sinne anderer Dateien. In einigen der obigen Fälle werden zuvor nicht zugewiesene Blöcke anstelle der Blöcke, die Ihre Daten enthalten, gelöscht. Es zerkleinert auch keine Metadaten im Dateisystem (was ich unter "Datei-Header" verstehe). Die Option -u versucht, den Dateinamen zu überschreiben, indem sie in einen neuen Namen derselben Länge umbenannt wird und dann jeweils das eine Zeichen auf 1 Zeichen verkürzt, bevor die Datei gelöscht wird. Sie können dies in Aktion sehen, wenn Sie -v ebenfalls angeben.

Answer 2

Das Problem besteht darin, dass Daten möglicherweise an mehreren Stellen auf der Festplatte vorhanden sind. Wenn die Daten an genau einem Ort existieren, kann shred diese Information deterministisch "löschen". Dateisysteme, die Journal oder andere erweiterte Dateisysteme verwenden, schreiben die Daten Ihrer Datei jedoch möglicherweise zeitweise auf mehrere Speicherorte auf der Festplatte. Shred - nach der Tatsache - hat keine Möglichkeit, darüber zu wissen und hat keine Möglichkeit zu wissen, wo die Daten vorübergehend auf die Festplatte geschrieben wurden. Daher gibt es keine Möglichkeit, diese Plattensektoren zu löschen oder zu überschreiben.

Stellen Sie sich vor: Sie schreiben eine Datei auf ein Journaled File System, das nicht nur Metadaten, sondern auch die Dateidaten erfasst. Die Dateidaten werden vorübergehend in das Journal geschrieben und dann an ihren endgültigen Speicherort geschrieben. Jetzt verwenden Sie Shred für die Datei. Der endgültige Ort, an dem die Daten geschrieben wurden, kann sicher mit Shred überschrieben werden. Allerdings müsste Shred etwas garantieren, dass die Sektoren in dem Journal, die vorübergehend den Inhalt Ihrer Datei enthielten, ebenfalls überschrieben werden, um versprechen zu können, dass Ihre Datei wirklich nicht wiederherstellbar ist. Stellen Sie sich ein Dateisystem vor, in dem das Journal nicht einmal an einem festen Ort oder von fester Länge ist.

Wenn Sie Shred verwenden, versuchen Sie sicherzustellen, dass Ihre Daten nicht rekonstruiert werden können.Die Autoren von Shred sind ehrlich, dass es einige Bedingungen außerhalb ihrer Kontrolle gibt, wo sie diese Garantie nicht leisten können.

Answer 3

Die anderen Antworten haben bereits eine gute Erklärung geliefert, warum Shred möglicherweise nicht in der Lage ist, seine Arbeit richtig zu machen.

Dies kann wie folgt zusammengefasst werden:

nur auf Partitionen arbeitet zerkleinern, nicht einzelne Dateien

Wie in den anderen Antworten erklärt, wenn Sie eine einzelne Datei Shred:

• dort ist keine Garantie, dass die tatsächlichen Daten wirklich überschrieben werden, da das Dateisystem Schreibvorgänge an dieselbe Datei an verschiedene Speicherorte auf Platte
• senden kann, gibt es keine g Stellen Sie sicher, dass die fs keine Kopien der Daten an anderer Stelle erstellt haben
• die fs könnte sogar entscheiden, Ihre Schreibvorgänge zu "optimieren", weil Sie die gleiche Datei wiederholt schreiben (Synchronisierung soll dies verhindern, aber wiederum: keine Garantie)

Aber auch wenn Sie wissen, dass Ihr Dateisystem nicht über eine der bösen Dinge tut, man muss auch bedenken, dass viele Anwendungen automatisch Kopien von Dateidaten erstellen werden:

• Crash-Recovery-Dateien welche Textverarbeitungsprogramme, Editoren (zB vim) etc. peri schreiben disch
• Thumbnail/Vorschaudateien in Dateimanager (manchmal auch für Nicht-Bilddateien)
• temporäre Dateien, die viele Anwendungen verwenden

Also, kurz jedes einzelnen binären Überprüfung Sie mit Ihren Daten verwenden zu arbeiten, Es könnte rechts, links & Zentrum ohne Sie wissen, kopiert worden sein. Der einzige realistische Weg besteht darin, immer komplette Partitionen (oder Festplatten) zu shredden.