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 bezeichne ich nachfolgend sowohl Partitionen als auch LVM-Volumes als “Volumes”. Wenn eine Unterscheidung notwendig ist, werde ich die explizit treffen. Für das root-Filesystem benutze ich die Abkürzung “/”-FS.

Das wichtigste Ergebnis unserer bisherigen Überlegungen war, dass wir das System, auf dem wir mit den zu schützenden Kundendaten arbeiten, voll verschlüsseln müssen. Das bedeutet, dass wir sowohl das Volume für das “/”-FS, als auch den SWAP sowie auch alle Volumes für Daten verschlüsseln. Es reicht nicht, mit Datencontainern zu arbeiten.

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 der Gastsysteme auf Host-Filesysteme geraten können.

Wir hatten ferner diskutiert, dass im Prinzip sowohl das Host-System auf dem Laptop als auch die Gast-Systeme selbst ihren Teil zur Verschlüsselung beitragen können. Dieses Thema hat nicht zuletzt 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 für Hosts und Gäste flexibel zu werden. Wie bringt man LVM mit der LUKS-Verschlüsselung zusammen? Wie stellt sich das im Fall von Virtualisierung dar?

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

Der nachfolgende Artikel geht aus grundlegender Perspektive auf diese Fragestellungen ein. Spätere Artikel widmen sich dann der praktischen Umsetzung.

Grundlegende Varianten der Schichtung von LVM- und LUKS-Layern

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 Gast-Systeme 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. Bei “LUKS on LVM” wird das LVM-Volume als sog. Raw-Volume verschlüsselt. Wir erkennen bereits hier, dass “LUKS on LVM” mehr Verschlüsselungskeys und zugehörige Passphrases erfordern wird als “LVM on LUKS”; jedes Volume wird bei “LUKS on LVM” ja für sich – also mit jeweils eigenen Master-Keys und ggf. unterschiedlichen Passphrases –
verschlüsselt.

Boot-Manager Grub2, Hibernation und zugehörige Varianten

Eine erste Frage, die sich stellt, ist die, ob der Boot-Manager spezielle Anforderungen an die Art der Schichtung stellt. Ich diskutiere das nachfolgend nur für den unter Linux üblichen Manager “Grub2”. Selbst dann gibt es aber noch mehrere Konfigurations-Varianten.

Unter Linux kann man etwa eine separate (verschlüsselte) Boot-Partition neben dem (verschlüsselten) 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”.

Die Komplexität steigt noch durch separate SWAP-Volumes/Partitionen, die Hibernation unterstützen sollen und selbst zu verschlüsseln sind. Der zuständige (Kernel-) Parameter ist “resume“; wir finden ihn in den relevanten Abschnitten der Datei “/boot/grub2/grub.cfg”. Gesteuert werden diese Einträge durch Vorgaben, die man unter Opensuse in der Datei “/etc/default/grub” verankert – u.a. Parameter für die Kernel-Commandline. Wir werden uns mit der korrekten Angabe von Device-Bezeichnungen in beiden genannten Konfigurationsdateien auseinander setzen müssen – für beide Schichtungsvarianten. Dabei sind u.a. UUIDs für die (Krypto-) Volumes von jenen der Filesysteme zu unterscheiden.

Generell stellt sich die Frage, ob sowohl ein normaler Systemstart als auch ein Start aus einem Hibernation-Zustand problemlos funktionieren, wenn wir den SWAP-Space in einem separaten verschlüsselten LVM-Volume unterbringen – also z.B. in einer Volume Group, die nicht das Volume für das “/”-FS enthält.

Wie gehen wir bzgl. separaten /boot- und SWAP-Volumes vor?

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 drei Varianten probieren:

• SWAP in einem Volume einer eigenen Volume Group [VG] mit “LUKS on LVM”. Dieser SWAP wird vom Betriebssystem in einem separaten Volume (einer weiteren VG) mit “LUKS on LVM” genutzt. (Die Trennung in 2 VGs erfolgt dabei vor allem aus Gründen der administrativen Übersichtlichkeit/Flexibilität und ist nicht zwingend).
• SWAP innerhalb einer Volumes einer umfassenden Volume Group für “LVM on LUKS”.
• Eine separate, mit Passwort verschlüsselte Partition außerhalb sonstiger LVM-Konstruktionen.

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. Den SWAP der Gastsysteme werden wir trotzdem verschlüsseln.

Einschränkungen durch Grub2 ?

Die positive Nachricht ist: Der Boot-Manager “Grub2” kann grundsätzlich mit “LUKS on LVM” und “LVM on LUKS” 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: Die schlechte Nachricht
Grub2 nutzt anscheinend einen ineffektiven Algorithmus bzgl. des Hashings und der PBKDF2-Iterationen (zumindest für SHA512). Die Zeit, die ein bereits aktiver Linux-Kernel für (cryptsetup benchmark) (mit HW-Unterstützung) für das Öffnen eines Krypto-Devices benötigt, ist kein Maßstab für die Zeit, die Grub2 in der ersten Boot-Phase für das Öffnen desselben Krypto-Devices benötigt. Hier ist Grub2 um einen Faktor 6 bis zu 10 bzgl. des benötigten Zeitbedarfs langsamer! Das sollte man beim LUKS-Setup unbedingt einkalkulieren. Ich habe das bislang unterschätzt und werde dazu in einem eigenen Artikel berichten.

Der Einfluss der Verfahren zur Erzeugung der initrd bzw. des initramfs sowie von plymouth während des Systemstarts

Der notwendige Zugriff von Grub2 auf verschlüsselte Volumes ist nur ein Aspekt des Starts voll verschlüsselter Linux-Systeme.
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. (Ob und wie man dabei eine erneute Eingabe von Passwörtern vermeiden kann, werden wir später am praktischen Beispiel studieren.) Im Falle eines Resume-Vorgangs aus einem Hibernation-Zustand muss der zwischenzeitlich geladene Kernel dagegen auf das verschlüsselte Volume für den SWAP zugreifen, ohne das “/”-FS (dauerhaft) zu mounten.

Linux ist nun leider nicht Linux. Die verschiedenen Distributionen setzen unterschiedliche Verfahren ein, um ein initramfs aus einer aktuellen Systemkonfiguration zu erzeugen (und/oder in Form einer initrd zu kapseln). Es ist logisch, dass die laufende Systemkonfiguration analysiert und das initramfs mit allen erforderlichen Treibern und Dateien ausgestattet werden muss. Opensuse nutzt für diese Aufgabe im Anschluss an Red Hat “dracut”. “dracut” wiederum triggert systemd-Generatoren – sowohl für das initramfs als auch das normale “/”-FS. Es ist dabei für einen einfachen Anwender leider kaum zu durchschauen, wie etwa ein Resume-Vorgang im Detail behandelt wird.

Ein Problem ergibt sich speziell im Fall von “LUKS on LVM”: Das System muss beim Booten aus einem Hibernation-Zustand das Volume für den Resume-Bereich (=SWAP) unabhängig vom Volume für das “/”-FS und einem evtl. RAM-FS entschlüsseln können. Das “/”-FS darf dabei in der Regel nicht gemountet sein! Wir werden (leider) sehen, dass deshalb z.B. das Einbinden eines Keyfiles, welches die Passphrase für das SWAP-Volume enthält und im verschlüsselten “/”-FS abgelegt wird, unter dracut und “LUKS on LVM” ein (bislang ungelöstes) Problem für eine Resume-Situation darstellt. Tricks und zugehörige Skripte, die unter Debian und abgeleiteten Derivaten alternativ genutzt werden (genannt sei etwa das Script “decrypt_derived”) sind unter dracut-lastigen Distributionen nicht einsetzbar.

Diese Einschränkungen für Opensuse Leap sind jedoch nicht grundsätzlicher Art; sie erschweren nur den praktischen Betrieb durch die Anforderung mehrfacher Passwort-Eingaben.

Der Linux-Systemstart hat durch Grub2 sowie systemd/udev bereits eine hohe Komplexität. Aber auch Plymouth wirkt sich zusätzlich auf den
Startvorgang voll-verschlüsselter Systeme aus. Während des Schreibens dieser Artikelserie haben sich die Auswirkungen von Plymouth dabei auch noch verändert – anscheinend zum Besseren. Ich komme darauf in späteren Artikeln zurück.

Vor- und Nachteile der Alternativen für die Schichtung

Welche der oben genannten zwei grundlegenden Schichtungs-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 eine relativ einfache Anpassung der der Größe von Volumes zu; das gilt vor allem dann, wenn man von vornherein eine ganze Disk (HD oder SSD) verschlüsselt. Problematischer ist hier aber die Einbindung weiterer kryptierte(n) Partitionen oder Platten als “Physical Volumes” [PVs] in vorhandene Volume Groups.
  Variante 1 erfordert von vornherein eine vorausschauende Planung der Menge an verschlüsseltem Plattenplatz, der die Grundbedürfnisse (von Host und Gästen) erfüllt. Das kann man als Nachteil sehen.
  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 Größenanpassungen von Volumes 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 wie verschlüsselt werden soll, kann man bedarfsgerecht verschieben. Das Hinzufügen neuer “Physical Volumes” zu eine Volume Group ist hier kein Problem. Das anschließende manuell Erweitern von verschlüsselten Logical Volumes ist mit ein wenig Übung beherrschbar.
  Variante 2 hat 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 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 während des Systemstarts zunächst nur das OS-Filesystem dekryptieren muss. Der entschlüsselnde Zugriff auf weitere Volumes kann später – ggf. manuell und mit eigenen Passwörtern – erfolgen.
  Ein weiterer Vorteil von Variante 1 ist, dass man 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 einer 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 viel komplexer. Das ist aber mehr ein Darstellungsproblem und hat damit zu tun, dass ich mehrere Möglichkeiten erfasst 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 ferner, 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.
Man beachte, dass Grub2 die Entschlüsselung des Volumes für das “/”-FS erfordert. Der Zugriff auf Volumes für den SWAP und weitere Volumes für Daten kann später durch den Kernel erfolgen. Das gilt auch für einen Resume-Prozess.

Für beide Varianten ist es durch Einsatz sog. Keyfiles und Anpassungen der initrd/initramfs möglich, die Eingabe von Passwörtern in einem normalen Systemstart auf die Grub-dominierte Phase zu beschränken .

Die Qual der Wahl
Ich will dem/r Leser/in bei seiner Entscheidung bzgl. der Schichtungs-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 sowohl in Variante 1 als 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. Grub2 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-eigene 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:

Filesysteme auf verschlüsselten Raw-Volumes kann ein Gast-System nach Öffnung des Volumes im Host selbst direkt mounten. Ein zusätzlicher Mount auf Verzeichnisse des Hosts ist überflüssig und wäre ein Zeichen für Daten-Zugriffe außerhalb des Normalbetriebs. Mount-Versuche von Filesystemen auf dem Host lassen sich aber gut überwachen und protokollieren. Sie erfordern ferner root-Rechte. Man kommt daher einer missbräuchlichen Nutzung der Filesysteme in “LUKS-on-LVM”-Volumes durch Unbefugte ggf. schneller auf die Spur. Sowohl Performance- als auch Sicherheitsgründe sprechen aus meiner Sicht also 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 “LUKS on LVM und “LVM on LUKS” studieren können.