Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout

In den letzten Beiträgen dieser Serie

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

haben wir bereits etliche wichtige Vorüberlegungen zur Voll-Verschlüsselung eines Linux-Laptops mit SSD unter Opensuse Leap 15 angestellt. Nun müssen wir noch planen, welche Partitionen das Layout unserer SSD prägen sollen.

Ich kann hier nur einen Vorschlag vorstellen, der u.a. durch Platz für virtualisierte Gastsysteme geprägt ist und den Test von "LUKS on LVM", "LVM und LUKS" sowie Hibernation ermöglicht. Bei mir persönlich gibt es dabei eine Präferenz für "LUKS on LVM".

SSD - Grundlayout

In meinem Fall ist die SSD eine Samsung 850 Pro. Darauf sind nominell 512 GB, also 476 GiB nutzbar. Davon lasse ich allerdings ca. 40 GiB unberührt. Die Samsung 850 EVO und PRO SSDs weisen auch ohne TRIM Operationen nur eine relativ geringe Geschwindigkeitsreduktion mit der Zeit auf:
https://www.tomshw.de/2014/07/01/samsung-ssd-850-pro-review-test/8/
http://www.martinzimelka.com/ homepage/ Blog/ Entries/ 2015/6/5-_Samsung_850-_EVO-_without-_TRIM.html

Nach allem, was ich weiß, hilft ein vollständig frei gelassener Plattenbereich dem internen SSD-Controller bei der zwingend notwendigen Garbage-Collection.

Nach meiner Erfahrung gilt allerdings auch, dass pro Partition ein gewisser Platz frei sein muss, um eine optimale Performance zu gewährleisten. Man darf die vorgesehenen Partitionen also nicht unterdimensionieren und die Möglichkeit vorsehen, diese bei Bedarf flexibel zu erweitern. Das spricht für den Einsatz von LVM. Die 40 GiB stellen hierfür auch eine eiserne Reserve dar.

Ich habe später nur eine Platte in meinem Laptop; Raid bleibt deshalb außen vor. Allerdings wollen wir beide im letzten Beitrag angesprochenen Schichtungs-Varianten (LVM on LUKS bzw. LUKS on LVM) testen. Dazu benötigen wir schon mal mindestens zwei Partitionen. Eine davon werden wir für LUKS on LVM als LVM-Volume-Group auslegen. Die zweite wird für Tests von LVM on LUKS herangezogen; wir erhalten so gleichzeitig ein zweites bootbares System. Eine separate Partition wird erforderlich für einen nutzbaren SWAP-Space, u.a. für Hibernation. Hinzu kommen eine Bios-Boot-Partition (passend zu meinem alten Laptop) und für einen evtl. späteren Wechsel in einen anderen Laptop vorsorglich auch eine EFI-Partition.

Die Platte selbst wird eine GPT-Layout (mit Protective MBR für Kompatibilität) erfahren.

Benötigte Partitionen und Platzaufteilung

Aus Erfahrung weiß ich ungefähr, was ich an Platz auf einzeln mountbaren Volumes benötige:

Bios-Boot-Partition [15 MB]
EFI-System-Partition [500 MB]

Partition => LVM VG (LUKS on LVM) 
SWAP-Partition [17 GiB] LUKS 1 Grub-Access

Partition => LVM VG (LUKS on LVM) 
/ (1) Host     [80 GiB] LUKS-1 Grub-Access
Guest WIN      [90 GiB] LUKS-2 indirekt mount
Guest Linux 1  [40 GiB] LUKS-2 indirekt mount
Home           [25 GiB] LUKS-2 "

Testpartition (LVM on LUKS) 
/ (2) Host     [40 GiB] LV LUKS-1 Grub Access
LV 2           [20 GiB] LV LUKS-1 (Testswap o.ä.) 

Weitere Partition für Daten (LUKS on LVM ?)  
Projekte       [25 GiB] LUKS-2 " - GIT 
Data           [80 GiB] LUKS-2 indirekt mount - SVN 
Guest 2        [20 GiB] LUKS-2

Ich habe jeweils auch angegeben, welche LUKS-Version ich verwenden werde und ob ein Grub2-Access erforderlich ist. Das Layout kann oder wird bei euch evtl. anders aussehen. Die nachfolgende Begründung für mein Layout kann daher nur Anregungen für ein eigenes Layout liefern.

Alles in allem verbraten wir so 432 GiB. Das "/"-Filesystem des hauptsächlich zu bootenden Host-Systems ist mit 80 GiB gut bemessen. Darin findet zur Not auch noch ein weiterer Linux-KVM/Qemu-Gast-Platz. Dass ich dem Windows-Gast potentiell so viel Platz einräume, hat mit Entwicklungs- und kundenspezifischen Tools zu tun. Das Home-Verzeichnis muss wegen Mail-Abgleichen und Musik-Dateien von vornherein relativ großzügig bemessen werden. Ob wir für die Daten-Volumes LUKS on LVM oder LVM on LUKS verwenden, lassen wir im Moment mal offen.

Die zu verschlüsselnde SWAP-Partition behandeln wir zunächst per LUKS on LVM. Sie ist größer als der RAM (bei mir 16 GB) gewählt; damit werden wir Hibernation testen. Ob für auch reines LUKS auf der SWAP-Partition funktioniert, werden wir später ausprobieren.

Viele LVM-Volumes mit separaten Passwörtern?

Ich hatte im letzten Beitrag dieser Serie eine Sympathie für "LUKS on LVM" erkennen lassen. Das steht im Gegensatz zu manchen Leitfäden im Internet. Aber: Flexibilität ist bei begrenztem Platz etwas Wichtiges. Und da halte ich es für besser, Volume Groups einfachst möglich um weitere Physical Volumes (= Partitionen) erweitern zu können. Es ist mir wichtig nachzuweisen, dass LUKS on LVM gut funktioniert - ohne dabei eine zu hohe Komplexität an Konfiguration zu erzeugen.

Der eine oder andere Leser wird sich dennoch wundern, wieso ich gleich so viele LVM-Volumes vorsehe. Jedes dieser Volumes benötigt ja bei LUKS on LVM ein eigenes Passwort - und die manuelle Eingabe wäre ausgesprochen unbequem.

Ein Grund für parallele Volumes ist die Koexistenz von LUKS-1 und LUKS-2. Ein zweiter Grund ist, dass ich die verschlüsselten Gastsysteme separat ansprechen und sichern können will! Zur Not auch mal von einem anderen oder externen System aus. Die zusätzliche manuelle Eingabe von Passwörtern für virtuelle Systeme, die man für die Arbeit mit Kunden vorsieht, kann auch als weitere Barriere für Angreifer angesehen werden.

Zudem gilt, dass man Passwörter für Verzeichnisse, die wir im Boot-Vorgang mounten, nicht unbedingt manuell eingeben muss. Grub fragt zunächst nur Passwörter für diejenigen Partitionen ab, auf die es gemäß der aktiven Boot-Einträge direkt zugreifen muss. Die Partitionen werden wir dabei durch UUIDs identifizieren lassen. Beim späteren Zugriff durch den von einer initrd unterstützten Kernel werden wir einen "Trick" verwenden, um weitere Passwortabfragen für regelmäßig benötigte Volumes wie "home, Projekte, Data" auch ohne manuelle Passwort-Angabe mounten zu können. Die Passwörter werden dabei in einem nur dem User "root" zugänglichen File hinterlegt.

Übrigens: Spürbare Performance-Nachteile gegenüber einer Variante "LVM on LUKS" habe ich im Betrieb bislang nicht feststellen können. Zwar muss der Host je nach Interaktion auf den Volumes zu unterschiedlichen Schlüsseln greifen - aber das bedeutet nur einen etwas anderen Speicherzugriff.

Ein weiterer Punkt: Im Boot-Vorgang wird bei der Berechnung des Master-Keys wegen des PBKDF2-Verfahrens Zeit pro Passwort-Eingabe verloren. Mein Artikel
Full encryption with LUKS (SHA512, aes-xts-plain64) – grub2 really slow …
zeigt aber, dass die Zeiten, die GRUB benötigt, viel größer als die eines bereits geladenen Kernels sein können. Es ist mit "LUKS on LVM" möglich, für virtuelle Systeme und Daten-Partitionen andere und größere Iterations-Parameter vorzugeben als für die durch Grub direkt anzusprechenden Partitionen.

Luks-2 ?

LUKS-2 ist seit Anfang dieses Jahres freigegeben. Das ist aus meiner Sicht im Opensource-Geschäft noch beta-Stadium ( 🙂 ). Luks-2 erlaubt u.a. komplexere Authentifizierungsverfahren - z.B. über ID-Cards. Und achtet auf die Konsistenz von Metadaten ... Siehe :
https://mbroz.fedorapeople.org/ talks/ DevConf2016/ devconf2016-luks2.pdf.
Wer dem Braten nicht traut, halte sich an LUKS-1! Generell möchte ich sagen, dass man mein Vorgehen nicht ohne vorheriges eigenes Denken übernehmen sollte. Setzt man LUKS-2 ein, so sind ggf. Backups auf LUKS-1-verschlüsselte Devices außerhalb des Laptops notwendig - aber regelmäßige Backups sind im professionellen Geschäft sowieso Pflicht!

So viel für heute. Im nächsten Beitrag werden die ersten der oben genannten Partitionen auf einer neuen, jungfräulichen SSD anlegen, verschlüsseln und für Tests vorbereiten. Ich werde die SSD für solche erste Tests in einer externen USB-Box unterbringen; dadurch können wir sie für Tests sowohl an einen Desktop wie auch an den Laptop selbst anschließen. Das ermöglicht es uns dann z.B., Unterschiede bzgl. des Zeitbedarfs für das PBKDF2-Verfahren zu messen. Die externe Box muss natürlich einen USB-to-SATA-Controller beinhalten. Deshalb werden wir uns - für manchen etwas überraschend - u.a. um das Thema des Partitions-Alignments kümmern müssen.