Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

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

hatten wir Vorüberlegungen zur Verschlüsselung eines Laptops angestellt. Wie in den früheren Beiträgen auch bezeichnen wir nachfolgend sowohl Partitionen als auch LVM-Volumes als "Volumes". Wenn eine Unterscheidung notwendig ist, werde ich die explizit treffen.

Das erste Ergebnis unserer Überlegungen war, dass wir das System, unter dem wir mit Kundendaten arbeiten, voll verschlüsseln müssen. Das bedeutet, dass wir sowohl das Volume für das Root-Filesystem als auch alle Volumes für Daten verschlüsseln. Es reicht nicht, mit Datencontainern zu arbeiten. Wir hatten auch eingesehen, dass alle global verfügbare Swap-Volumes verschlüsselt werden müssen.

Unser zweites Ergebnis war: Wir sollten diesen Ansatz auf einem Virtualisierungs-System (LVM/QEMU, LXC) zur Sicherheit sowohl auf die Volumes anwenden, die der Host selbst nutzt, als auch auf alle Volumes, die von den Betriebssystemen der Gäste genutzt oder zusätzlich gemountet werden. Sprich: Auch der Virtualisierungshost muss voll-verschlüsselt werden (Root-Filesystem, Swap (!), Daten-Volumes). Es gibt zu viele Faktoren, durch die Inhalte des Gastsystems auf Host-Filesysteme geraten kann.

Wir hatten ferner diskutiert, dass im Prinzip sowohl das Hostsystem auf dem Laptop als auch die Gastsysteme ihren Teil zur Verschlüsselung beitragen können. Dieses letzte Thema hat auch mit der Schichtung der Zugriffsverfahren auf Storage-Devices und Filesysteme zu tun. Jeder, der mit Linux professionell arbeitet, nutzt früher oder später LVM, um bzgl. der Anpassung der Größe von Filesystemen flexibel zu werden. Wie bringt man LVM mit Verschlüsselung zusammen? Wie stellt sich das im Fall von Virtualisierung dar?

Ein anderer für die Praxis sehr wichtiger Punkt ist die Kompatibilität mit Boot-Managern. Kann der unter Linux wohl hauptsächlich eingesetzte Grub2-Manager mit verschachtelten LVM/LUKS- oder LUKS/LVM-Strukturen auf Block-Devices umgehen?

Grundlegende Varianten der LVM-LUKS-Zugriffsschichtung

Sind die HDD/SSD-Devices des Laptops nicht in Raid-Systeme eingebunden, so sind zunächst zwei grundsätzliche Varianten denkbar, wenn Host- und/oder Gastsysteme verschlüsselte Volumes verwenden wollen:

  1. Variante 1 - LVM on LUKS : Partitionen  >>  dm-crypt/LUKS  >>  LVM  >>  Volumes  >>  ...  >>  Filesysteme
  2. Variante 2 - LUKS on LVM : Partitionen  >>  LVM  >>  Volumes  >>  dm-crypt/Luks  >>  ...  >>  Filesysteme

(Die Punkte "..." stehen stellvertretend für weitere Layer wie Virtualisierung ; s.u.). Es geht bei den Alternativen also darum, ob man zuerst kryptiert und dann LVM nutzt oder umgekehrt.

Boot-Manager Grub2 - und die Varianten

Eine erste Frage, die sich stellt, ist die, ob ggf. der Boot-Manager spezielle Anforderungen hinsichtlich der Schichtung stellt. Ich diskutiere das nachfolgend nur für den unter Linux üblichen Manager "Grub2". Das ganze Thema Boot-Manager und verschlüsselte Partitionen ist deutlich komplexer, als man auf den ersten Blick meinen möchte - und es gibt viele Varianten, die mit der Verteilung der Boot-Informationen und dem Auslesen in Phasen durch GRUB-Prozesse zusammenhängen.

Unter Linux kann man etwa eine separate Boot-Partition neben dem Volume für das "/"-Filesystem nutzen. Dann muss der Boot-Manager ggf. nacheinander beide Partitionen/Volumes auslesen können, mindestens aber mal die Boot-Partition. Und das unabhängig von LVM on LUKS oder LUKS on LVM. Hinzu kommt die zwischenzeitliche Einblendung eines Filesystems im RAM per initrd/initramfs (aus dem "/boot"-Verzeichnis bzw. der Boot-Partition), mit dessen Hilfe der erste vollständige Zugriff auf das "/"-Filesystem (Mount) und ggf. weitere Volumes gesteuert wird. Dies bedeutet, dass auch die per initrd/initramfs initial bereitgestellten Treiber mit LVM und LUKS zurecht kommen müssen. (Wie man dabei eine erneute Eingabe von Passwörtern vermeiden kann, werden wir später am praktischen Beispiel studieren.)

Die Komplexität steigt noch durch SWAP-Volumes/Partitionen, die Hibernation unterstützen sollen und die deshalb selbst zu verschlüsseln sind. Der zuständige (Kernel-) Parameter ist "resume"; wir finden ihn in den relevanten Abschnitten der "/boot/grub.cfg" Auch hier stellt sich die Frage, ob alles noch funktioniert, wenn wir den kryptierten SWAP-Space in einem LVM-Volume unterbringen. Ein Thema ist, dass das System im Fall des Bootens aus einem Hibernation-Zustand den Resume-Bereich (=SWAP) unabhängig vom Volume für das root-Filesystem und einem später geladenen RAM-FS entschlüsseln können muss. Und ggf. trotz einer unterlegten Logical Volume Group [VG].

Mir persönlich ist die Einrichtung einer separaten Boot-Partition, die ggf. zu verschiedenen OS-Installationen auf dem Laptop passen muss, regelmäßig zu komplex. Ich entscheide mich eher für die Installation des Boot-Managers aus einer "Leit"-OS-Installation heraus, wobei während der Installation auf weitere OS getestet wird. (Dazu muss man vor der Einrichtung alle Volumes mit OS-Installationen temporär entschlüsseln). Die OS-Installationen haben dann jeweils ihr eigenes "/boot"-Verzeichnis innerhalb des jeweiligen "/"-Filesystems auf dem zur Installation gehörigen verschlüsselten Volume.

Bzgl. des SWAP-Spaces und Hibernation werden wir zwei Varianten probieren:

  • SWAP mit "LUKS on LVM" werden wir auch mal ausprobieren.
  • Eine separate, mit Passwort verschlüsselte Partition außerhalb sonstiger LVM-Konstruktionen.

Siehe hierzu die zweite der Abbildungen weiter unten. Für virtualisierte Gast-Systeme werden wir ein unabhängiges Hibernation dadurch unterbinden, dass wir den "resume"-Parameter für dortige Gast-Boot-Manager nicht definieren und stattdessen den Kernel-Parameter "noresume" angeben. Ist Hibernation auch auf dem Virtualisierungshost selbst kein Thema, dann hat man kein Problem mit einem verschlüsselten SWAP. Er kann von systemd des bootenden Systems gem. "/etc/fstab" eingehängt werden. Wie man dabei die Eingabe eines Passworts umgeht, werde ich später in dieser Artikelserie zeigen.

Einschränkungen durch Grub2 ?
Die positive Nachricht ist: Der Boot-Manager "Grub2" kann grundsätzlich mit beiden Alternativen umgehen. Sogar, wenn diese auf ein mdadm-SW-Raid aufgesetzt werden. Die negative Einschränkung ist: Alle verschlüsselten Partitionen/Volumes, die von GRUB2 angesprochen werden, dürfen nur mit "LUKS1" und nicht mit LUKS2 verschlüsselt werden.
Merke:

Der aktuelle Zustand von Grub2 (11/2018) schränkt den Spielraum bei der Wahl der LUKS-Version für das Volume mit dem "/"-Filesystem eines (Virtualisierungs-) Hosts und ggf. separate SWAP-Volumes/Partitionen auf LUKS-1 ein! Das Gleiche gilt aber auch für Gastsysteme, falls diese selbst die Verantwortung für die Verschlüsselung der von ihnen genutzten Volumes mit Filesystem für das Gast-OS übernehmen sollen.

Weitere Volumes für Daten können vom Host und Gastsystemen allerdings mit LUKS2 kryptiert werden. Das gilt dann auch für Volumes, die Gastsystemen vom Host zur Verfügung gestellt werden, soweit allein der Host die Aufgabe ihrer Ver-/Ent-Schlüsselung übernimmt.

Addendum 30.11.2018:
Es gibt auch eine schlechte Nachricht: Grub2 hat anscheinend einen ineffektiven Algorithmus bzgl. des Hashings und der PBKDF2-Iterationen (zumindest für SHA512). Hier muss man unbedingt experimentieren - denn die Zeit, die ein bereits aktiver Kernel für (cryptsetup benchmark) (mit HW-Unterstützung) benötigt, ist kein Maßstab für die Zeit, die Grub in der ersten Boot-Phase benötigt. Hier sind Faktoren bis zu 10 bzgl. des benötigten Zeitbedarfs möglich! Ich habe das bislang unterschätzt und werde dazu in einem eigenen Artikel berichten.

Vor- und Nachteile der Alternativen

Welche der oben genannten grundlegenden Varianten man wählt, sollte man nicht nur nach Gusto entscheiden. Ich liste mal ein paar Aspekt auf, über die es sich lohnt nachzudenken:

  • Variante 1: Sie lässt z.T. eine einfachere Anpassung der der Größe von Volumes als Alternative 2 zu; das gilt vor allem dann, wenn man von vornherein eine ganze Disk verschlüsselt. Problematischer ist hier aber die Erweiterung um weitere kryptierte(n) Partitionen als "Physical Volumes" [PVs]; s.u.. Ansonsten kann der Platzbedarf teilweise sogar im laufenden Betrieb angepasst werden.
    Variante 1 erfordert allerdings von vornherein eine durchdachte Planung der Menge an verschlüsseltem Plattenplatz, der die Grundbedürfnisse (von Host und Gästen) erfüllt.
    Variante 1 hat den Vorteil, dass man die LVM-Volume-Struktur hinter dem Einheitsbrei verschlüsselter Blöcke verbirgt.
    Ein weiterer Vorteil ist, dass man im Bedarfsfall nur ein Passwort einer großen Partition benötigt, um eine ganze LVM-Struktur zu entschlüsseln. Setzt man allerdings auf einen umfassenden Verschlüsselungsbereich, ist man wegen Begrenzungen von Grub2 auf LUKS1 beschränkt.
  • Variante 2: Diese Variante erfordert bei Anpassungen mehr manuelle Eingriffe. Jedes Volume ist separat zu verschlüsseln und erfordert ein eigenes Passwort; das kann man übrigens auch als Vorteil und zusätzliche Sicherheitshürde für Angreifer sehen.
    Variante 2 hat den Vorteil, dass man die Volumes erst bei Bedarf aufbauen kann. Auch die Entscheidung, was verschlüsselt werden soll, kann man bedarfsgerecht verschieben. Auch das Hinzufügen neuer "Physical Volumes" zu eine Volume Group ist hier kein Thema. Das anschließende manuell Erweitern von Logical Volumes ist mit ein wenig Übung beherrschbar.
    Variante 2 hat aber auch den Nachteil, dass man die LVM-Struktur offen legt. Einem Angreifer kann bereits die Größe und Benennung der Volumes Hinweise darauf geben, worauf er sich konzentrieren sollte.
    Variante 2 bietet übrigens größere Flexibilität bei der Platzverteilung, wenn man neben voll verschlüsselten Installationen auch separate unverschlüsselte Installationen zulassen will.
    Ein weiterer Vorteil ist, dass man zunächst nur das OS-Filesystem dekryptieren muss. Der Zugriff auf weitere Volumes kann später (und mit eigenen Passwörtern) erfolgen. Ein weiterer Vorteil von Variante 1 ist, dass man flexible Volumes auch mit LUKS2 verschlüsseln kann.

Der Vollständigkeit halber wollen wir auch nicht verschweigen, dass es auch auf Laptops Raid-Systeme geben kann. Die Raid-Schicht sollte immer die unterste darstellen (s. hierzu den letzten Link oben). Die nachfolgende Grafiken verdeutlichen den Aufbau - inkl eines Raid-Layers.

Illustration Variante 1 (LVM on LUKS):

Anmerkung zu Variante 1:
Die Abbildung verdeutlicht u.a. das Thema der potentiell mehrfachen Passwort-Eingabe im Boot-Vorgang - einmal bei Grub2 und einmal im Zuge von Kernel-Prozessen, die mit Hilfe von Treibern der initrd auf die Devices zugreifen.
Dargestellt ist oben auch, dass wir ggf. auch zwei (oder mehr) verschlüsselten "Physical Volumes" [PV] zu eienr Volume Group zusammenbinden wollen. In vielen Artikeln im Internet ist Variante 1 allerdings nur für genau eine verschlüsseltes größere Partition beschrieben oder gleich eine ganze Disk, die dann per LVM unterteilt wird. Es erhebt sich die Frage, ob sich der Ansatz unter Linux (und speziell unter Opensuse) auf mehrere verschlüsselte Partitionen erweitern lässt, die dann als "Physical Volumes" [PVs] zu einer "Volume Group" [VG] zusammengebunden werden. Ein solches Szenario ist etwa denkbar, wenn man nicht von vornherein den gesamten Plattenplatz geopfert hat - oder aber eine 2-te Disk in den Laptop einbaut. Es ist klar, dass im Verlauf des Boot-Vorgangs nicht nur GRUB, sondern auch eine initrd (bzw. initramfs) damit klar kommen muss.
Angeblich hilft einen Option "-C" beim Einsatz von "mkinitrd". Ich habe das selbst nie ausprobiert und weiß auch nicht, wie unter Opensuse "dracut" darauf reagiert. Siehe aber für Nicht-Opensuse-Systeme (Debian) die folgenden Hinweise:
https://www.howtoforge.com/encrypted-root-lvm
https://www.linuxquestions.org/questions/slackware-14/root-partition-spanning-multiple-luks-volumes-4175460525-print/
Ich werde diese Unter-Variante in meinem Fall nicht weiter verfolgen. Variante 2 ist bzgl. des Hinzufügens neuer Physical Volumes zu einer Volume Group einfacher; dabei fallen auch keine neuen Passwörter an.

Illustration Variante 2 (LUKS on LVM):

Anmerkung zu Variante 2:
Die Darstellung wirkt auf den ersten Blick sehr viel komplexer. Das ist aber mehr ein Darstellungsproblem und hat auch damit zu tun, dass ich mehrere Möglichkeiten dargestellt habe: Das Daten-LV wird mit mit LUKS2 statt LUKS1 verschlüsselt. Zudem sind zwei Möglichkeiten der Etablierung eines SWAP-Devices dargestellt - einerseits über eine separate Partition, andererseits über ein LV. Man beachte, dass der LVM-Aufbau klarer als in Variante 1 ist und nicht durch die Kryptierung durchbrochen wird. Der Nachteil der potentiell mehrfachen Passwort-Eingabe im verlauf des Boot-Vorgangs wird auch hier wieder deutlich.

Für beide Varianten ist es durch Anpassungen der initrd/initramfs möglich, die Eingabe von Passwörtern auf die Grub-Startphase zu beschränken.

Die Qual der Wahl
Ich will dem/r Leser/in bei seiner Entscheidung bzgl. der Varianten nicht vorgreifen; persönlich finde ich Variante 2 letztlich flexibler. Dem Punkt mit der Offenlegung der LVM-Struktur kann man durch eine neutrale Wahl der Volume-Bezeichnungen etwas entgegenwirken. Eine größere Menge an Volumes ist am Schluss genauso diffus wie ein Einheitsbrei. Anpassungen sowohl im Sinne einer Volume- und Filesystem-Vergrößerung wie auch -Verkleinerung sind natürlich auch in Variante 2 möglich. Siehe hierzu beispielsweise:
Shrinking an encrypted partition with LVM on LUKS.

Unter folgendem Link findet man eine kurze Diskussion der beiden Haupt-Varianten: https://superuser.com/questions/1193290/best-order-of-raid-lvm-and-luks.

Einbindung der Virtualisierung

Im letzten Artikel hatte ich bereits diskutiert, dass man Virtualisierung ggf. benötigt, um Arbeits- und Kundendomänen abzugrenzen sowie MS-Clients bereit zu stellen. Virtualisierung schiebt sich nun mitten in die obigen Varianten rein.

1) LVM on LUKS mit Virtualisierung:
Plattenpartitionen für Raid  >>  RaidX  >>  Storage-Devices  >> 
Partition(en)  >>  dm-crypt/LUKS1 (erkannt durch Grub und Host)  >> 
|__ Verschl. Partitionen oder LVM-Volumes für KVM-Host-OS mit passender initrd  >> 
|__ Filesysteme des Hosts mit passender initrd  >>
|__ Weitere LVM-Volumes  >>  Dekryptierung durch Host/Gast  >> 
Gastsysteme mit Zugriff auf LVM-Volumes als virtuelle Platten (Raw disk image device)  >> 
|__(LVM /Volumes (oder Partitionen) für Gastsystem)  >>  ext4-Filesysteme des Gastsystems

2) LUKS on LVM mit Virtualisierung:
Plattenpartitionen für Raid  >>  Raid X  >>  Storage-Devices  >> 
|__Partitionen oder LVM-Volumes für KVM-Host-OS  >>  dm-crypt/LUKS1 (Grub, Host)  >> 
|__ Filesysteme des Hosts mit passender initrd  >> 
|__Partitionen oder weitere LVM-Volumes  >>  dm-crypt/LUKS2 (Host)  >> 
Gastsysteme mit Zugriff auf die Volumes als virtuelle Platten (raw disk image device)  >> 
|__ ( LVM /Volumes oder Partitionen im Gastsystem )  >>  ext4-Filesysteme des Gastsystems

Der Leser hat sicher gemerkt, dass ich eine zweite zusätzliche Verschlüsselungsebene im Gast-System nicht vorgesehen habe. In der modifizierten Variante 2) soll die Entschlüsselung und Verschlüsselung der Volumes für die Gastsysteme vom Host vorgenommen werden. Das eröffnet uns nebenbei die Möglichkeit, die Volumes für die Gast-Systeme vollständig mit LUKS2 zu verschlüsseln.

Hinweis:

Die Volumes für die Gastsysteme müssen auf dem Host nicht gemountet werden; sie müssen dort vor dem Start des jeweiligen Gastes lediglich als dekryptierte LVM-Devices (unter "/dev/mapper") bereitstehen.

Alternativ kann aber auch der Gast die von ihm genutzten Volumes ent- und verschlüsseln; das sieht für Variante 2 dann wie folgt aus:

2.1) LUKS on LVM mit Virtualisierung:
Plattenpartitionen für Raid  >>  Raid X  >>  Storage-Devices  >> 
|__Partitionen oder LVM-Volumes für KVM-Host-OS  >>  dm-crypt/LUKS1 (Grub, Host)  >> 
|__ Filesysteme des Hosts mit passender initrd  >> 
|__Partitionen oder weitere LVM-Volumes  >>  dm-crypt/LUKS1/2 (Gast)  >> 
Gastsysteme mit Zugriff auf die Volumes als virtuelle Platten (Raw disk images)  >> 
|__ ( LVM /Volumes oder Partitionen im Gastsystem )  >>  ext4-Filesysteme des Gastsystems

Dabei muss man dann aber auf den Einsatz von LUKS1 für das Volume mit dem zu bootenden Filesystem des Gastes achten. Grub im Gastsystem arbeitet dann ja auf einem verschlüsselten Device!

Hinweis:

Am Ende des letzten Beitrags hatte ich bereits darauf aufmerksam gemacht, dass es je nach Anzahl der von den Gast-Systemen genutzten CPU-Threads sinnvoll sein kann, die Verschlüsselung der Volumes für die Gäste gänzlich dem Host zu überlassen.

qcow2-Dateien im Fall von Virtualisierung?

Es gibt noch einen weiteren Weg, wie man KVM/QEMU-Gastsysteme auf verschlüsselten Devices (des Hosts) unterbringen kann: qcow2-Dateien. Hierbei nutzt man eine definierte Datei, die der Host auf einem verschlüsselten Volume bereitstellt, als Storage-Device für das Disk Image der virtuellen Maschine. (Siehe auch: https://www.qemu.org/2018/02/09/understanding-qemu-devices/). Qcow2-Dateien bieten viel Vorteile (einfache Sicherung; einfacher Umzug zu anderen Host-Systemen, ...), auf die ich hier nicht im Detail eingehen kann.
Ein Thema ist hierbei allerdings, dass das verschlüsselte Volume zunächst entschlüsselt und auf dem Host auch gemountet werden muss, bevor das Gast-System es nutzen kann:
Alle Storage-Zugriffe des Gastes führen hier nicht nur über das Gast-eigenen Filesystem und über den Krypto-Layer des Hosts, sondern zusätzlich auch noch über die Filesystem-Schicht des Hosts. Das bringt schon mal Nachteile in der Performance. es gibt aber auch einen Sicherheitsaspekt:

Raw-Devices kann ein Gast-System nach Entschlüsselung am Host dagegen direkt mounten. Ein zusätzlicher Mount im Filesystem des Hosts ist überflüssig und wäre ein Zeichen für daten-Zugriffe außerhalb des Normalbetriebs . Mount-Versuche auf dem Host lassen sich aber gut überwachen und protokollieren. Sie erfordern ferner root-Rechte. Man kommt daher einer missbräuchlichen Nutzung von LVM-Volumes für Gastsysteme durch Unbefugte ggf. schneller auf die Spur. Sowohl Performance- als auch Sicherheitsgründe sprechen aus meiner Sicht dafür, auf einem Laptop mit KVM/QEMU-Virtualisierung auf qcow2-Images zu verzichten und die Gäste statt dessen (kryptierte) LVM-Volumes als Raw-Devices nutzen zu lassen.

Fazit

Durch die Layer-Struktur für den Zugriff auf Block-Devices ((Raid - LVM- LUKS) entsteht eine relativ hohe Komplexität bei der Einrichtung von voll-verschlüsselten Systemen. Dabei ist von vornherein auf eine Kompatibilität mit dem Boot-Manager Grub2 zu achten - und bedarfsgerecht zwischen einer Verschlüsselung mit LUKS1 und LUKS2 zu unterscheiden. Im Boot-Vorgang müssen sowohl GRUB als auch Prozesse, die auf eine initiale RAM-Disk (initrd/initramfs) zugreifen, mit den verschlüsselten und zu mountenden Volumes klar kommen. Die Unterstützung von Hibernation erfordert dabei ggf. besondere Vorkehrungen bzgl. Swap-Partitionen oder Volumes.

Im nächsten Beitrag

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

werde ich einen konkreten Vorschlag für ein Platten-Layout diskutieren, mit dem wir beide Varianten studieren können.