Ich lese immer noch 2x:
Diesen Vorgang abhängig vom Sicherheitsbedürfnis mehrfach wiederholen.
Anmeldungsdatum: Beiträge: 17576 Wohnort: Berlin |
Ich lese immer noch 2x:
|
Anmeldungsdatum: Beiträge: 19197 |
Hm, hab ich wohl übersehen? Eigentlich überschreibt es doch nur freie Inodes und freien Speicher? Wenn man die Sache detailliert betrachtet, kommt sowieso noch das Problem dazu, dass die Dateisysteme nur bestimmte Blockgrößen (üblicherweise 4KB) ansprechen können und somit Dateien in den letzten 4KB meist noch alte Daten von überschriebenen Dateien beinhalten. Diese lassen sich auch nicht überschreiben. Lassen sich aber auch nicht so einfach wiederherstellen. |
(Themenstarter)
Anmeldungsdatum: Beiträge: Zähle... |
@user unknown: Der entsprechende Satz ist jetzt umformuliert. @stfischr: Ich kenne mich bezüglich Metadaten nicht genau aus. Ich dachte, dass das Überschreiben der Inodes reicht. Da dem offensichtlich nicht so ist, habe ich den Hinweis auf nicht gelöschte Metadaten in die allgemeine Warnung mitaufgenommen. Bezüglich deines zweiten Punktes hast du Recht. Auf dieses Problem bezieht sich der Satz "Bei dieser Methode wird eine geringe Menge des Speichers nicht überschrieben.". Hälst du den Satz für zu unklar? |
Anmeldungsdatum: Beiträge: 17576 Wohnort: Berlin |
Das war also:
und ist nun:
Was ist daran denn anders, außer dass es länger und bla-faseliger ist? Wieso sollte man das als nicht ausreichend betrachten? Reicht aus für was? |
Anmeldungsdatum: Beiträge: 19197 |
Achso, ne ok, dass sollte ausreichen.
Ich wäre dafür, es an den Anfang in den Hinweiß zu verschieben:
bei sfill dann noch einen Hinweis, mit welchem Parameter man mehrere Durchgänge erreichen kann. |
Anmeldungsdatum: Beiträge: 7735 |
Mehrfach überschreiben ist unnötig. Einfach reicht. /dev/random (dauert Jahrhunderte) und /dev/urandom (dauert Tage) benutzt kein Mensch zum Überschreiben: Das sind Zufallsquellen z.B. für 512 Byte Keys o.ä., für gigabyteweise Daten sind sie leider viel zu langsam. /dev/zero wird aus zwei Gründen empfohlen: 1. Es ist schnell 2. Nullen reichen auch aus. Der Punkt 2.) beginnt allerdings zu wackeln. Es ist zwar ausreichend mit Nullen zu überschreiben. Aber die Nullen müssen auch tatsächlich geschrieben werden. Bei traditionellen Festplatten und Dateisystemen ist das der Fall. Kein Problem. Aber die Speichergeräte und Dateisysteme machen derzeit eine Entwicklung zu mehr "Intelligenz" durch. SSDs haben TRIM und Komprimierung, und geTRIMte Bereiche liefern beim Lesen: Nullen. Dateisysteme haben sparse files, diese Dateien liefern beim Lesen: Nullen. Wenn nun Nullen geschrieben werden, kann ein intelligentes Dateisytem oder eine intelligente Festplatte sagen: Oh toll, der schreibt Nullen, da mache ich jetzt sparse oder TRIM oder ich komprimiere das. Da beim Lesen anschließend korrekt wieder Nullen zurückgeliefert werden, ist das erlaubt. In so einem Fall wären die Nullen aber nie tatsächlich geschrieben worden und somit auch keine Daten überschrieben und somit auch nichts tatsächlich physikalisch gelöscht. Hier ist man dann wieder bei Zufallsdaten: Solange dem Dateisystem der PRNG-Seed nicht bekannt ist, können Zufallsdaten nicht reproduziert und auch nicht komprimiert werden. Um die gleichen Daten wieder zurückliefern zu können, müssen sie also zwangsweise geschrieben werden. Wer also Zufallsdaten schreibt und korrekt wieder einliest, hat also die Garantie die bei Nullen fehlt, nämlich daß tatsächlich physikalisch geschrieben und gelöscht worden sein muß. Es ist dann (wenn man das gesamte Gerät überschreibt) wirklich nur noch die nicht direkt ansprechbare Sektor-Reserve übrig. Für diese müßte man sich, sofern vorhanden, auf die ata-secure-erase Funktion verlassen. Der Kernel bietet leider keinen schnellen PRNG, daher muss man auf sowas wie shred oder (wenn man selber scripten will) Python's numpy.random.bytes() oder vergleichbares ausweichen. Sonstige Fehler die mir im Artikel aufgefallen sind: sudo cat /dev/zero >muelldatei Das führt unnötigerweise cat als sudo aus. /dev/zero darf man auch mit normalen Userrechten lesen. Das sudo betrifft leider nicht die >, die Mülldatei wird also ohne Root-Rechte geschrieben und erwischt damit nicht die möglicherweise vorhandene Root-Reserve des Dateisystems. Die meisten Befehle die per sudo irgendwas pipen wollen machen das mit tee oder so. sudo dd if=/dev/zero of=muelldatei Oder so. Warum dann noch das cat? Man sollte bei dd allerdings noch ein bs=1M o.ä. anfügen, da dd mit default bs=512 sehr langsam arbeitet.
Gutmann hat seine Theorien nie nachgewiesen und ist mehrfach widerlegt. Zigmal überschreiben ist nicht notwendig. Und diesen Aberglauben sollte man nicht weiter verbreiten. |
Ehemaliger
Anmeldungsdatum: Beiträge: 29552 Wohnort: WW |
Hallo, @frostschutz: Danke für den ausführlichen Post! Damit wäre das mit Gruß, noisefloor |
Anmeldungsdatum: Beiträge: 7735 |
Das Problem bei /dev/(u)random ist die Langsamkeit. Wer (bei urandom) mit 5-10MB/s glücklich ist... Für schnelle Zufallszahlen braucht man einfach einen anderen Zufallszahlengenerator - shred hat einen und ist fast überall installiert und auch zum Überschreiben von Geräten gedacht, bietet sich daher an mit einem Durchgang (shred -n 1) laufen zu lassen. Ich denke daß auch noch bei vielen SSDs /dev/zero OK ist, aber man kanns halt nicht ohne weiteres nachprüfen, und die Entwicklung geht allgemein zu intelligenteren Laufwerken, und Dateisystemen (ZFS, btrfs) die noch allerhand mehr machen, Komprimierung unterstützen usw. Festplatten gibts auch schon in Hybridform (HDD+SDD Kombi mit SSD als Cache). Da weiß man dann halt nicht mehr genau was passiert, wenn man Nullen schreibt - darum Zufallszahlen, weil die nicht wegkomprimiert, wegoptimiert, usw. werden können, sondern das Dateisystem und das Laufwerk zwingen, tatsächlich zu schreiben. Nur den freien Speicher eines Dateisystems mit shred zu überschreiben ist nun etwas kompliziert da das ein Device braucht. Man könnte jetzt mit dd eine große Zero-Datei erstellen und die dann shredden, aber das wären dann zwei Schreibvorgänge und würde somit doppelt so lange dauern wie nötig. Wenn das Dateisystem sparse files unterstützt könnte man es so machen: dd of=muelldatei count=0 bs=1G seek=1G Das erstellt eine Exabyte große muelldatei. (Ohje) .ohne zu schreiben. Und darauf läßt man dann shred los: shred -n 1 muelldatei Das gibt dann irgendwann einen out of space blablubb error da shred ja kein Exabyte vollschreiben kann. Dann macht man sync (damits tatsächlich geschrieben wird) und loescht das wieder sync rm muelldatei Ist natürlich auch nicht ideal da shred ja intelligent genug sein könnte um zu erkennen, das muelldatei nur sparse ist und da nichts zu überschreiben ist. Da müsste man dann ein loop-device zwischenschalten. Und bei Dateisystemen die sparse nicht unterstützen hilfts eh nicht. Ansonsten eben mit einer anderen Zufallsdatenquelle, ich nutze ganz gerne Python/numpy, aber das ist halt nur begrenzt Wiki-tauglich da nicht überall installiert. Ich kenne leider kein Standard-Tool, das als allgemeine (pipebare) schnelle Zufallsdatenquelle herhalten kann... shred schreibt leider nicht auf stdout (oder ich weiß nicht wie). |
Anmeldungsdatum: Beiträge: 17576 Wohnort: Berlin |
Wenn man vermitteln will, dass man weiß was man sagt, dann sagt man nur was man sagen will. Ich meine, als Eltern geht man aus der Wohnung und sagt zu den Kindern:"Ihr bleibt im Bett." - nicht "Ihr bleibt im Bett - auf ZDF läuft übrigens Championsleague". Wenn man meint dass niemand ein mehrmaliges Überschreiben braucht, dann braucht man nicht zu erklären wie es geht. Das nennt man in anderen Zusammenhängen Wort-Bild-Schere, oder Wasser predigen - Wein trinken, oder "Tu was ich sage - nicht was ich mache!", oder "geheimer Subtext": Niemand braucht es, aber wir Illuminaten ...". ☺ |
(Themenstarter)
Anmeldungsdatum: Beiträge: 337 |
@stfischr: Ich habe den entsprechenden Hinweis in die Warnungsbox verschoben. sfill ganz ohne Parameter (so wie beim ersten Befehl unter "Methode 3") läuft mehrfach. @frostschutz: Danke für den ausführlichen Beitrag zu SSDs. Ich habe einen entsprechenden Hinweis in die Warnungsbox geschrieben und deinen Beitrag verlinkt. Ich habe Methode 1 und Methode 2 aufgeführt, da ich beides in diversen Foreneinträgen gefunden habe. Dadurch lässt sich vielleicht Unklarheit und Unsicherheit vermeiden, warum eine Methode immer wieder genannt wird, aber in diesem Wikiartikel nicht auftaucht. Ich habe nicht genau verstanden, ob das Problem der Root-Reserve auch bei Methode 2 (dd) auftritt, oder nur bei Methode 1 (cat). Weißt du auch zu dd genaueres? Verstehe ich das richtig, dass bei der Option "bs=1M" ein größerer Bereich am Ende unüberschrieben bleibt? Ich habe diese von dir in deinem letzten Beitrag beschriebenere Methode für SSDs nicht eingefügt. Möchtest du vielleicht selbst eine "Methode 4" einfügen? |
Anmeldungsdatum: Beiträge: 7735 |
Das dd ist schon richtig, das meinte ich mit "oder so". Den Befehl mit cat sollte man einfach rauswerfen. Wichtig ist das sync vor dem rm, sonst hat man den Dateisystemcache überschrieben aber den freien Speicher nicht (oder nicht alles).
Nein, das Endergebnis ist haargenau das gleiche; das ist nur die Blocksize mit der dd intern arbeitet. Bei doppelter Blocksize halbiert sich dementsprechend die Anzahl der read()/write() syscalls. Und jeder syscall ist Overhead der Zeit braucht, das ist bei 512 Byte dann selbst auf schnellen Maschinen langsamer als eine herkömmliche Festplatte. Methode muss ich mir eine überlegen die nicht zu verworren ist. Geräte kann man mit shred, aber Dateien ist halt blöd, da mit sparse oder Python oder sonst komischen Konstrukten herumzumachen... |
Anmeldungsdatum: Beiträge: 9245 |
Ich bin immer noch der Meinung, das sich dieses Thema und Daten sicher löschen soweit überschneiden, das ein Artikel reicht. So wie ich das verstehe, gelten die Ausführungen von frostschutz teilweise ja auch für Daten sicher löschen (Hinweisbox). |
Ehemalige
Anmeldungsdatum: Beiträge: 4259 |
Wie soll es hier weitergehen? Doublette → einstellen? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 337 |
Hm, also ich habe die meisten vorgeschlagenen Änderungen eingepflegt. Wie gesagt kann dieser Artikel auch gerne in Daten sicher löschen eingearbeitet werden. |
Ehemalige
Anmeldungsdatum: Beiträge: 4259 |
Da Du ja am Besten in der Materie (Deines Artikels) drin bist, würdest Du das Einarbeiten übernehmen wollen? Dann könnte die Dauerbaustelle weg. Gruss |