[gelöst]Verschlüsselte Partition über NFS

[halo44]

Ich benötige mal wieder sachkundigen Rat. Diesmal zum Thema „NFS-Mount einer verschlüsselten Partition“.

Auf meinem alten Rechner, den ich ausschließlich für Sicherungen benutze, habe ich auch eine verschlüsselte Datenpartition angelegt, die ich gelegentlich von meinem Hauptrechner über NFSv4 mounte und per rsync aktualisiere.

Das funktioniert auch eigentlich ganz gut, wenn man davon absieht, daß beim „Abschliessen“ der Partition (umount und luksClose) hin und wieder die Meldung kommt, daß das unter /dev/mapper eingebundene Gerät „beschäftigt“ sei. Dem habe ich allerdings nie besondere Bedeutung beigemessen, da immer die eigentliche Datenpartition als auch die Freigabe untehalb des NFS-Pseudo-Verzeichnisses leer waren. Nach dem nächsten Hochfahren war nämlich das vormals „beschäftigte“ Gerät unter /dev/mapper brav entfernt.

Nun habe ich es allerdings jetzt einmal geschafft, daß anscheinend der umount-Befehl für die verschlüsselte Datenpartition erfolgreich war. Nicht aber cryptsetup mit luksClose. Jedenfalls war die Datenpartition leer, aber das Freigabeverzeichnis unterhalb des NFS-Pseudoverzeichnisses enthielt noch alle Dateien (unverschlüsselt).

Bemerkt habe ich das, als der Rechner nicht mehr hochfuhr, d.h. es erschienen nur drei der fünf Icons (Festplatte, Werkzeug und Weltkugel) beim Starten von KDE und der Rechner blieb hier hängen. Nach langem Warten erfolgte ein Hinweis auf „tmp is out of space“.

Daraufhin fuhr ich den Rechner mit der Bootoption für den Runlevel 3 hoch. Das Verzeichnis tmp wies für mich keine Besonderheiten auf. Allerdings entdeckte ich das „Malheur“ mit den vorliegenden unverschlüsselten Daten.

Mutig (oder unvorsichtig?), wie ich bin, löschte ich einfach die Inhalte des Unterverzeichnisses, beendete und fuhr erfolgreich neu hoch. Nach Mounten der verschlüsselten Datenpartition waren alle Daten wieder da.

Die Welt scheint also jetzt in Ordnung zu sein.

Nun aber zu meiner eigentlichen Frage: da ja alle Daten unverschlüsselt im NFS-Unterverzeichnis vorlagen (ohne, daß die eigentliche Datenpartition gemountet war), müssen sie ja irgendwo gespeichert gewesen sein. Vermutlich auch deshalb der Hinweis auf „tmp out of space“.

Wo lagen die Daten vor? Vielleicht in swap? Oder wo sonst?

Hintergrund der Frage: liegen meine Daten jetzt noch irgendwo unverschlüsselt auf einer Festplatte? Habe ich damit meine Verschlüsselung ungewollt unterlaufen?

Sollte ich die Partition auf dem Sicherungsrechner komplett neu einrichten? Oder ist das unnötig?

Danke für Eure Ratschläge.

Gruß H.

 

[lOtz1009]

Ich vermute sie lagen einfach im Einhängeverzeichnis.
Kann es evtl. sein, dass das die verschlüsselte Partition nicht eingehängt war (den Pfad gibt es ja dann trotzdem und damit ist das "Laufwerk" auf Seite des Clients verfügbar), und rsync die Daten dann überspielt hat?

Ist mir bei einem Backup mal passiert. Da lagen die Daten dann in /mnt/backup, allerdings nicht auf dem Laufwerk, da dieses dort nicht eingehängt war

 

[halo44]

Vermutlich hast Du mich mißverstanden:

Der Rechner, der nicht hochfuhr, war der Server. Auf dem Client war nichts gemountet, da ich im Skript dort mounte, rsync fahre und wieder unmounte.

Die Daten lagen unverschlüsselt im NFS-Pseudo-Verzeichnis des Servers.

Oder bin ich hier der, der mißversteht? :???:

Gruss H.

 

[lOtz1009]

Naja, was ich meine wäre folgende Situation auf dem Server:

+ verschlüsseltes Laufwerk (enthält deine Daten)
+ Einhängepunkt (enthielt die selben Daten)
------------------------------------------------
= Daten x 2

Was natürlich dazu führen kann, dass die Platte voll ist.

 

[halo44]

Naja, was ich meine wäre folgende Situation auf dem Server:

+ verschlüsseltes Laufwerk (enthält deine Daten)
+ Einhängepunkt (enthielt die selben Daten)
------------------------------------------------
= Daten x 2

Was natürlich dazu führen kann, dass die Platte voll ist.

Das kann nicht die Ursache sein, da dieser Zustand immer dann gegeben ist, wenn die Partition entschlüsselt und anschließend für NFS bereitgestellt wird. Wie Du richtig schreibst, sind es die selben Daten. Also sind sie nicht wirklich zweimal da, auch wenn Du sie immer zweimal im Verzeichnisbaum findest. Beide Verweise beziehen sich meinem Verständnis nach auf die physisch gleichen Daten.

Mein Problem war, daß sie nur einmal da waren und das im "falschen" Verzeichnis, wo sie eigentlich garnicht sein konnten, weil die verschlüsselte Quell-Partition garnicht gemountet war. Also ein Zustand, der merkwürdigerweise doch auf ein zweimaliges physisches Vorhandensein schliessen liesse.

Deswegen auch meine "Befürchtung", daß die Daten noch irgendwo unverschlüsselt vorhanden sind.

Gruss H.

 

[lOtz1009]

Auch auf die Gefahr hin, dass wir aneinander vorbei reden

Wenn ich z.B. auf dem Server ein verschlüsseltes Laufwerk /dev/mapper/nfscrypt habe, welches in /mnt/nfscrypt eingehängt wird, dann befinden sich die Daten physisch in /dev/mapper/nfscrypt.

Ist dieses Laufwerk nicht eingehängt, aber der Pfad /mnt/nfscrypt vorhanden, wird rsync gnadenlos die Daten in /mnt/nfscrypt schreiben, was dazu führt, dass die Daten eben zusätzlich physisch in /mnt/nfscrypt vorhanden sind. Je nach Größe ist das /-Laufwerk dann so voll, dass in /tmp nicht mehr geschrieben werden kann.

 

[halo44]

... wird rsync gnadenlos die Daten in /mnt/nfscrypt schreiben, was dazu führt, dass die Daten eben zusätzlich physisch in /mnt/nfscrypt vorhanden sind. Je nach Größe ist das /-Laufwerk dann so voll, dass in /tmp nicht mehr geschrieben werden kann.

Tatsächlich, ich habs eben getestet und es ist so, wie Du sagst. Ich danke Dir für Deine Geduld. Jetzt weiß ich zunächst einmal, wie das Malheur passieren konnte.

Damit beantwortet sich aber auch meine eigentliche Frage nach dem physischen Vorhandensein meiner Daten. Das Sicherheitsproblem scheint mir gegeben, weil ich ja die im Einhängeverzeichnis vorhandenen Daten nur mit

rm -rf *

gelöscht habe, womit sie physisch noch auf der Platte (unverschlüsselt) vorhanden sind.

Was kann ich machen? Muss ich das Einhängeverzeichnis mit Zufallszahlen vollschreiben, bis die Platte wieder zu ist? Oder passiert das nicht, weil der Datenbereich ja nicht reserviert wird?

Für eine Antwort auch auf diese Frage wäre ich dankbar.

Gruss H.

 

[lOtz1009]

Ich würde fast behaupten dass ein dd if=/dev/zero of=/wo/auch/immer bis zum Volllaufen für Otto-Normal ausreicht. Damit ist der gesamte freie Speicherplatz mit Nullen überschrieben.

 

[halo44]

Hab ich gemacht - alles bestens.

Danke nochmal.

Gruss H.

 

[halo44]

Ich melde mich zum Thema noch mal zu Wort, da ich festgestellt habe, daß ich im Eingangspost offensichtlich verschiedene falsche Vermutungen von mir als Tatsachen gewertet habe.

Nachdem ich das ganze Szenario heute einmal in allen Variationen mit dem Sicherungsserver durchgetestet habe, steht fest, daß IOtz1009 schon in seinem ersten Post "den Nagel auf den Kopf getroffen" hat.

Ich vermute sie lagen einfach im Einhängeverzeichnis.
Kann es evtl. sein, dass das die verschlüsselte Partition nicht eingehängt war (den Pfad gibt es ja dann trotzdem und damit ist das "Laufwerk" auf Seite des Clients verfügbar), und rsync die Daten dann überspielt hat?

Ist mir bei einem Backup mal passiert. Da lagen die Daten dann in /mnt/backup, allerdings nicht auf dem Laufwerk, da dieses dort nicht eingehängt war

Ich habe ganz offensichtlich vergessen auf dem Server die entschlüsselten Daten ins NFS-Verzeichnis zu mounten. Rsync hat sie dann gnadenlos dorthin gesynct und Schluss gemacht, als der freie Platz der root-Partition erschöpft war. Damit ließ sich anschließend das System nicht mehr hochfahren.

Ich hab mein Sicherungsskript auf dem Client jetzt dahingehend geändert, daß ich nach dem mounten des Freigabeverzeichnisses zunächst prüfe, ob die Daten dort vorliegen. Wenn nicht, breche ich mit Fehlermeldung ab.

Gruss H.