staging.inyokaproject.org

Sollte statt einer Komplettverschlüsselung nur Home oder dergleichen verschlüsselt werden, müssen mehrere Sachen beachtet werden, damit der Schutz nicht unterminiert wird.

Dazu habe ich den Artikel Baustelle/Vorbereitung zur Teilverschlüsselung erstellt. Der Name ist nur ein Platzhalter, wer eine bessere Idee hat, immer her damit. Auch wenn außer den Dreien noch etwas beachtet werden muss.

Ist tmpfs automatisch pro Mount auf 50% begrenzt? Damit könnte man sich theoretisch dann 100% zubauen.

*edit* Ok, Du hast Recht. Das sollte aber kein Problem sein, da /var/tmp so gut wie nicht benutzt wird afaik. Andererseits könnte ich ja die fstab-Zeile anpassen.

TMP zu verschlüsseln ist um einiges komplizierter. Ich muss mal schauen, ob die cryptsetup-Scripte dafür irgendetwas mitbringen.

In Zukunft könnte im Verschlüsselungsartikel über die Home-Partition noch ein Teil über die Schlüsselableitung eingestellt werden. Dann könnte mit dem Kennwort der Swap auch die Home freigeschaltet werden, für ältere Laptops halt.

unggnu schrieb:

TMP zu verschlüsseln ist um einiges komplizierter. Ich muss mal schauen, ob die cryptsetup-Scripte dafür irgendetwas mitbringen.

Hm, warum? Man kann ja eine Partition oder Container-Datei per crypttab mit Zufallsschlüssel einbinden - wie Swap, oder?

Und wenn man /tmp ausdrücklich auf 50% begrenzt und /var/tmp auf 25%, ist das abgesichert. ☺

Ich habe /var/tmp jetzt einfach als Link erstellt. So habe ich es im Prinzip auch immer früher bei mir gemacht.

75% wären im worst case schon ein wenig viel. Ich denke, dass das so Ok ist.

Cryptsetup bietet tatsächlich eine eigene Option für TMP-Verzeichnisse.

Inhaltlich sollte der Artikel jetzt vollständig sein, denke ich.

Was noch fehlt ist das Überschreiben des ungenutzten Speichers. Im Prinzip sollte es "cat /dev/zero > LoeschMich" tun, aber vielleicht hat jemand eine bessere Idee. Das wäre sicher nicht perfekt, aber besser als gar nichts. Außerdem müsste es theoretisch auf jeder Partition einmal durchgeführt werden, auf der sich zu verschlüsselnde Dateien befanden.

*edit* Ich habe das Bearbeiten-Feld jetzt raus genommen. Sind sicher noch einige Rechtschreibfehler und dergleichen drin, sollte aber funktionieren.

Seit Jaunty gibt es auch das Tool ecryptfs-setup-swap, dass die Verschlüsselung der Swap ein wenig einfacher machen sollte, aber dann würde das ganze [noch] unübersichtlicher, deswegen habe ich es weggelassen. Außerdem müsste dafür im Regelfall ein extra Paket installiert werden.

Da keine Einwände vorliegen - verschoben, danke. ☺

Mir ist durch eine UUID-Diskusion in einem anderen Thread aufgefallen, dass die temporäre Swap und TMP-Verschlüsselung gefährlich werden könnte, sollte sich die Devicenamen ändern, durch z.B. den Einbau einer weiteren Festplatte oder der Änderung der Bootreihenfolge.

Theoretisch würde cryptsetup dann ungefragt die Partition überschreiben, zumindest den Anfang. Gibt es da irgend einen Schutz vor? UUIDs kann man ja nicht verwenden, da die Partitionen bei jedem Start neu generiert wird.

Da man eines der beiden Merkmale braucht, um eine Partition zu identifizieren kann man das nicht lösen.

Persönlich würde ich dazu tendieren, aufgrund dieses Risikos die entsprechenden Abschnitte aus dem Artikel zu entfernen - für eine Teilverschlüsselung also nur der Betrieb ohne SWAP und mit TMP im RAM.

Wer Ruhezustand, etc. will, soll voll verschlüsseln.

Bei der Ruhezustands-Version besteht die Gefahr nicht, da die UUID generiert wird und solange tmp im Arbeitsspeicher landet auch nicht. Die Gefahr besteht halt nur für die temporäre Verschlüsselung der Swap und von TMP.

Vielleicht reicht eine Warnung, nur wird sich wahrscheinlich daran bei entsprechender Änderung sowieso keiner mehr erinnern. Am besten wäre es, wenn cryptsetup nur Partitionen mit inkorrektem Header ungefragt überschriebe, aber dafür benötigte es logischerweise einen Patch.

Ich habe jetzt mal eine Warnung eingefügt. Der Rest ist Sache der User und des Zufalls. 😀

Bessere Formulierungen sind immer willkommen ☺

Da UUID in der /etc/crypttab nicht direkt geht, wäre dann nicht ein Eintrag mit /dev/disk/by-uuid sinnvoll?

swap  /dev/disk/by-uuid/e03f4d77-ee58-4f32-8003-dce7ae413156  /dev/urandom  swap,cipher=aes-xts-plain,size=256

Damit würde man die Gefahr, bei einem Umbau Daten zu verlieren, minimieren, oder?

Das Problem ist das bei jedem Boot die Partition mit einem neuen Passwort und Dateisystem formatiert wird. Das heißt die UUID ist immer eine andere. Deswegen bringt es nichts eine UUID in der fstab einzutragen.

Gruß, unggnu

Artikel ist ungetestet

GUten morgen ☺

frustschieber schrieb:

Artikel ist ungetestet

Nein, Hardy Server wird noch bis 2013 unterstützt 😉

Gruß
kaputtnik