Komplettverschlüsseln mit LUKS - LVM oder nicht?

[chr.gogolin]

Ich möchte gerne auf einen Notebook mit SSD ein komplett verschlüsseltes dual boot System mit LUKS aufsetzten. Als Dateisystem soll btrfs zum Einsatz kommen.

Wenn ich das richtig sehe big es im wesentlichen zwei Möglichkeiten das anzustellen:

1) /efi + ... + /boot + dm_cypt&LUKS{ LVM[ btrfs( root, ... ), swap ] }
Das wäre wohl die "klassische variante mit einem LVM im dm-crypt.

2) /efi + ... + /boot + dm_cypt&LUKS{ btrfs( root, ... ) } + dm_cypt&LUKS{ swap }
Das wäre die etwas "unkonventionellere" Variante mit je einem dm-crypt device für root bzw. swap. Den Schlüssel für letzteres würde ich dann mit der unter [1] beschriebenen Technik von ersterem "ableiten".

Da btrfs schon vieles von dem kann was was ich sonst mit LVM machen würde und ich mir nicht sicher bin wie gut die SSD optimierungen von btrfs noch funktionieren wenn es unter LVM läuft, würde ich eigentlich gerne auf LVM verzichten.

Suspend to disk (hibernation) sowie booten müssten, wenn ich das richtig verstehe, bei beiden Varianten mit nur einmal Passwort eingeben funktionieren.

Gibt es irgendwelche Gründe (Wartbarkeit, Fehleranfälligkeit, Flexibilität mit der Partitionierung, Probleme bei zukünftigen Updates, ...) die gegen Variante 2 sprechen?

Kann der Installer eine der beiden (oder beide) Varianten über die manuelle Partitionierung direkt einrichten?

[1] https://wiki.ubuntuusers.de/System_vers ... ableitung/

Hintergrund: Debian läuft so gut, dass ich seit fast sieben Jahren mein Hauptsystem nicht mehr neu installiert habe. Aktuell verwende ich ein Debian stable das auf einem Lenny von 2009 beruht. Nun werde ich demnächst mein ebenfalls seit 2009 in täglichem Betrieb befindliches ThinkPad x301 gegen neuere Hardware tauschen und da sich einiges getan hat in den 201Xer Jahren dachte ich, ich sollte mal neu installieren. Leider sind meine Kenntnisse in der lange Zeit etwas eingerostet, gleichzeitig bin ich ein Freund langfristiger Lösungen und möchte daher alles richtig machen. Dazu brauche ich eure Hilfe...

[NAB]

[1] https://wiki.ubuntuusers.de/System_vers ... ableitung/

Wenn groß in Rot "Achtung!" drüber steht, dann sollte man es unbedingt ignorieren

[chr.gogolin]

Wer lesen kann ist klar im Vorteil. Also dann wohl wieder mit LVM bis btrfs igendwann endlich mal verschlüsselung oder swapfile kann. Danke!

[gehrke]

Ich bin seit Jahren mit der Kombination LUKS+LVM zufrieden - Deine erste Variante. Allerdings zugegebenermaßen vornehmlich mit anderen Distributionen.

Bei BTRFS würde ich mir seehr genau ansehen, ob die erwarteten Lösungen tatsächlich auch schon umgesetzt sind und de facto funktionieren. Und wenn sie funktionieren, ob auch alle zusätzlich verwendeten Tools damit klar kommen (Beispiel Backup). Hier bevorzuge ich derzeit noch die gut abgehangene LVM-Variante mit ext4.

EDIT: Die Variante LUKS+LVM(+MD_ADM) konnte der Installer von wheezy.

[NAB]

Nunja, das ist zumindest der Weg, den der Debianinstaller vorgibt und der somit auch bei zukünftigen Updates funktionieren wird. Alles andere läuft auf "Bastelei" hinaus.

Du kannst zum Beispiel mit einem Keyfile statt mit "decrypt_derived" arbeiten. Das musst du dir aber eigenhändig zurechtbasteln. Ob das die Mühe wert ist, weiß ich nicht.

btrfs kennt übrigens eine Mountoption, die die ssd-Optimierungen einschaltet, unabhängig davon, was für ein Medium erkannt wurde.

Beachte, dass der Installer den gesamten verschlüsselten Container mit Zufallszahlen vollschreibt. Die SSD erkennt dann keine ungenutzten Blöcke mehr, TRIM funktioniert dann nicht mehr. Auch das wear-leveling könnte behindert werden. Ich behelfe mir damit, dass ich 10% der SSD ungenutzt lasse - also unpartitioniert und unbeschrieben - in der Hoffnung, dass die SSD dann in diesem Bereich ungenutzte Blöcke findet, wenn mal einer kaputt ist. Ob das wirklich was bringt, weiß ich nicht!

Und beachte, dass du einen Prozessor mit Hardware-Verschlüsselung (AES-NI) haben willst. Bei Intel ist das z.B. erst ab Skylake durchgängig der Fall.

[chr.gogolin]

Ok, wow, genau das ist das Wissen was ich hier so schätze.

EDIT: Die Variante LUKS+LVM(+MD_ADM) konnte der Installer von wheezy.

Ok, super. Danke!

Nunja, das ist zumindest der Weg, den der Debianinstaller vorgibt und der somit auch bei zukünftigen Updates funktionieren wird. Alles andere läuft auf "Bastelei" hinaus.

Bastelei bin ich grunsätzlich nicht abgeneigt, aber wenn es einen offiziellen Weg gibt, dann sollte man den wohl wählen.

btrfs kennt übrigens eine Mountoption, die die ssd-Optimierungen einschaltet, unabhängig davon, was für ein Medium erkannt wurde.

Ah, gute Info! Aber funktionieren die dann auch so wie wenn es ohne dm-crypt direkt auf dem block device der SSD laufen würde?

Beachte, dass der Installer den gesamten verschlüsselten Container mit Zufallszahlen vollschreibt. Die SSD erkennt dann keine ungenutzten Blöcke mehr, TRIM funktioniert dann nicht mehr. Auch das wear-leveling könnte behindert werden.

Ist das wirklich so? Laut [2] geht ab einem 3.1 Kernel auch trim mit cryptsetup. Mit den theoretischen Sicherheitseinbußen könnte ich gut leben. Es geht mir nur darum dass ich ruhig schlafen kann wenn mir jemand das Notebook klaut.

Und beachte, dass du einen Prozessor mit Hardware-Verschlüsselung (AES-NI) haben willst. Bei Intel ist das z.B. erst ab Skylake durchgängig der Fall.

Ja, wird wohl ein Skylake i5.

[2] http://asalor.blogspot.com.es/2011/08/t ... blems.html

[NAB]

Ist das wirklich so? Laut [2] geht ab einem 3.1 Kernel auch trim mit cryptsetup. Mit den theoretischen Sicherheitseinbußen könnte ich gut leben. Es geht mir nur darum dass ich ruhig schlafen kann wenn mir jemand das Notebook klaut.

Ja, das ist wirklich so, widerspricht aber nicht der Möglichkeit, nachher TRIM zu aktivieren ... dann werden die Blöcke vom Dateisystem wieder als leer gekennzeichnet, und du hast die erwähnten theoretischen Sicherheitseinbußen

Du könntest die ganze Sache übrigens einfach mal in einer VM durchexerzieren ... mit "Expert Install" und "manual partitioning" kannst du problemlos ein Debian ohne Swap in einen verschlüsselten Container ohne LVM legen, und dann nach der Installation ein per Keyfile verschlüsseltes Swap hinzufügen ... sonderlich schwer ist das nicht

Und ich habe keine Ahnung, wie gut Skylake unter einem 3.16er Kernel von Debian Stable läuft ... zumindest mit der 3D-Beschleunigung dürftest du Probleme bekommen. Eventuell hältst du eine DVD mit Backports-Kerneln bereit.

[chr.gogolin]

Ist das wirklich so? Laut [2] geht ab einem 3.1 Kernel auch trim mit cryptsetup. Mit den theoretischen Sicherheitseinbußen könnte ich gut leben. Es geht mir nur darum dass ich ruhig schlafen kann wenn mir jemand das Notebook klaut.

Ja, das ist wirklich so, widerspricht aber nicht der Möglichkeit, nachher TRIM zu aktivieren ... dann werden die Blöcke vom Dateisystem wieder als leer gekennzeichnet, und du hast die erwähnten theoretischen Sicherheitseinbußen

Ok, dann mache ich das wohl so.

Du könntest die ganze Sache übrigens einfach mal in einer VM durchexerzieren ... mit "Expert Install" und "manual partitioning" kannst du problemlos ein Debian ohne Swap in einen verschlüsselten Container ohne LVM legen, und dann nach der Installation ein per Keyfile verschlüsseltes Swap hinzufügen ... sonderlich schwer ist das nicht

Ja, das werde ich vielleicht mal probieren. Aber wenn die Hardware erst mal da ist kann ich auch gleich damit rumspielen und nebenbei noch eine weile mein altes Produktivsystem verwenden....

Und ich habe keine Ahnung, wie gut Skylake unter einem 3.16er Kernel von Debian Stable läuft ... zumindest mit der 3D-Beschleunigung dürftest du Probleme bekommen. Eventuell hältst du eine DVD mit Backports-Kerneln bereit.

Bei so neuer Hardware lohnt ein neuer Kernel sicher. Ich werde stretch installieren und dann bei stable bleiben wenn es stable ist.