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 etliche Vorüberlegungen zur Voll-Verschlüsselung eines Linux-Laptops mit SSD unter Opensuse Leap 15 angestellt. Für die anstehenden Tests muss ich noch planen, welche Partitionen das Layout meine (noch jungfräuliche) SSD prägen sollen. Ich kann hier natürlich 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öglichen soll. Bei mir persönlich gibt es zudem eine Präferenz für “LUKS on LVM”.
Das root-Filesystem bezeichne ich nachfolgend mit “/”-FS.
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. Nach allem, was ich weiß, hilft ein vollständig frei gelassener Plattenbereich dem internen SSD-Controller bei der zwingend notwendigen Garbage-Collection. Garbage Collection ist nicht das Gleiche wie trimmen. Mit Einstellungen für das Durchschleusen von TRIM-Aktionen durch die LVM und LUKS-Layer werde ich mich noch gesondert in einem kommenden Artikel befassen.
Die Samsung 850 EVO und PRO SSDs weist aber 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 meiner Erfahrung gilt allerdings, dass auch pro Partition ein gewisser Platz frei sein muss, um auf Dauer eine optimale Performance zu gewährleisten. Man darf die vorgesehenen Partitionen also nicht unterdimensionieren und muss die Möglichkeit vorsehen, diese bei Bedarf flexibel zu erweitern. Das spricht für den Einsatz von LVM. Die 40 GiB stellen in diesem Kontext nicht zuletzt 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 Physical Volume [PV] für eine LVM-Volume-Group [VG] heranziehen. Die zweite wird für Tests von “LVM on LUKS” herangezogen; wir erhalten so gleichzeitig ein zweites bootbares System.
Eine dritte separate Partition nutze ich für den SWAP-Space und Test von Hibernation. Diese Partition stützt als PV eine eigene VG. 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 erhält ein GPT-Layout (mit Protective MBR für Kompatibilität).
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 VMW-Guest WIN [90 GiB] LUKS-2 indirekt mount KVM-Guest 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 indirektes Mount - SVN KVM Guest 2 [20 GiB] LUKS-2
Ich habe angegeben, welche LUKS-Version ich jeweils verwenden werde und ob ein Grub2-Access erforderlich ist.
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 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. 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 wichtiger Grund für weitere Volumes ist die Koexistenz von LUKS-1 und LUKS-2. LUKS-2 bietet ein avanciertes PBKDF-Verfahren (argon2i) und sorgt für Konsistenz auf der Ebene der verschlüsselten Blöcke. Ein Einsatz ist für alle Volumes möglich, auf die GRUB2 nicht zugreifen muss.
Ein zweiter Grund ist, dass ich die verschlüsselten KVM- und VMware-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. Grub2 fragt zunächst nur Passwörter für diejenigen Volumes/Partitionen ab, auf die es gemäß der aktiven Boot-Einträge direkt zugreifen muss. Das ist bei “LUKS on LVM” vor allem das Volume mit dem “/”-FS.
Beim späteren Zugriff durch den Kernel werden wir einen “Trick” verwenden, um regelmäßig benötigte Volumes wie “home, Projekte, Data” auch ohne manuelle Passwort-Eingabe mounten zu können. Die Passwörter werden dabei in einem nur dem User “root” zugänglichen sog. Key-File im (verschlüsselten) “/”-FS 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, sicherheitsrelevanter Punkt ist folgender:
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, 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 (2018) 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! Setzt man LUKS-2 ein, so sind ggf. Backups auf LUKS-1-verschlüsselte Devices außerhalb des Laptops sinnvoll!
So viel für heute. Im nächsten Beitrag
werde ich 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.