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

Diese Artikelserie behandelt die Verschlüsselung eines Laptops unter Opensuse Leap 15.0. Nicht nur die DSGVO verlangt von IT-Freelancern Verschlüsselung als Teil eines Katalogs von Maßnahmen zum Schutz personenbezogener Daten von Kunden. Das fängt u.a. beim Austausch von Mails mit Kundenvertretern an. Da Sicherheit nicht durch Verschlüsselung irgendwelcher Partitionen entsteht, hatten wir im letzten Beitrag
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
mit Vorüberlegungen zur Voll- oder Teil-Verschlüsselung begonnen. Ein Punkt, auf den ich dabei noch nicht eingegangen bin, ist das Thema Virtualisierung: Ein moderner Laptop kann selbstverständlich auch als Host für virtualisierte Gastsysteme eingesetzt werden.

Ein typischer Anwendungsfall für einen Freelancer, der primär auf Linux setzt, ist die Virtualisierung von MS-Windows-Gastsystemen. (Leider braucht man für die effiziente Kooperation mit den meisten Kunden ja weiterhin MS-Windows Programme 🙁 ) Weil wir gerade dabei sind: Als Linux-Profi ist man sich hoffentlich der Tatsache bewusst, dass virtualisierte Windows-10-Clients in Standardausführung zumindest potentiell eine Bedrohung der gesamten Geheimhaltungskette darstellen können (https://www.lda.bayern.de/media/windows_10_report.pdf; Heise Artikel zum Bundesclient). Wir werden dieser Problematik im Rahmen der Artikelserie noch mal gesondert Raum widmen müssen.

Virtualisierung ist aber auch unabhängig von Windows-Gastsystemen ein gutes Mittel zur Separation von Arbeits- und Kunden-Domänen. Insbesondere kann man die Netzwerkfähigkeiten von Gastsystemen jedweder Art für den kundenbezogenen Einsatz auf ganz bestimmte Server - z.B. die des Kunden - einschränken. Web-Browsing und den nicht kundenbezogenen Mail-Verkehr verlagert man dagegen auf einen anderen abgegrenzten Gast des Laptop-Hosts mit minimaler Ausstattung. (Nebenbei: Die Abtrennung von Prozessen und Daten von Gästen gegeneinander und gegenüber dem Host ist bei KVM/QEMU-Vollvirtualisierung aus Sicherheitssicht deutlich besser gewährleistet als bei Containern.) Virtualisierung bietet also zusätzliche Möglichkeiten, die Sicherheit insgesamt zu verbessern. Man sollte das Thema deshalb im Kontext einer Verschlüsselungsstrategie berücksichtigen. Ich gehe im vorliegenden Beitrag allerdings nur auf einige Aspekte des Themas "Virtualisierung und Verschlüsselung" ein. Ich bezeichne dabei - wie im letzten Beitrag - sowohl LVM-Volums als auch echte Partitionen als "Volumes".

Voll-Verschlüsselung virtualisierter Gast-Systeme - Varianten

Spricht man über Virtualisierung und Verschlüsselung, so ist zwischen den Gastsystemen, dem Host und den jeweiligen Storage-Systemen zu unterscheiden. Meine im ersten Artikel angegebene Liste von Devices, die im Rahmen einer Vollverschlüsselung kryptiert werden müssen, relativiert sich deshalb: Meint man den Storage des Hosts, meint man dem Gastsystem zugeordnete Devices, meint man beides? Wir konzentrieren uns gedanklich zunächst auf die Voll-Verschlüsselung des Gastsystems - und sehen, wie weit wir damit kommen. Dieser Ansatz entspricht dem eines unverschlüsselten Laptop-Hosts mit einem oder mehreren "voll verschlüsselten virtuellen Gast-System(en)" (z.B. unter KVM/QEMU).

Dafür gibt es technisch mehrere Lösungen:

  1. Das virtuelle System kann in einem oder mehreren mit LUKS verschlüsselten Volume/s des Hosts untergebracht werden. Der Host sorgt dann dafür, dass nur verschlüsselte Daten auf die Storage-Systeme des Gastes geschrieben werden.
  2. Wie Punkt 1; dem Gastsystem wird allerdings erlaubt, ergänzend aber auch selbst weitere kryptierte Daten-Volumes zu mounten und bzgl. dieser Devices über den eigenen Kernel und LUKS für die Verschlüsselung sorgen.
  3. Das Gastsystem wird von vornherein so installiert, dass es selbst für die Verschlüsselung sämtlicher von ihm benutzten Storage Devices sorgt - u.a. auch des Devices mit dem eigenen root-Filesystem.

Paranoide können natürlich auch Variante 1 und 3 kombinieren - und so zwei ineinandergreifende Schichten der Verschlüsselung aufbauen. Das wird sich aber womöglich in einer Reduktion der Performance niederschlagen. Eine weitere Variante wäre die, das root-Filesystem des virtualisierten Systems in einem datei-basierten Krypto-Container zu nutzen. Die unten diskutierten Konsequenzen sind im Wesentlichen aber vergleichbar mit jenen, die sich aus der Variante (1) ergeben.

Daten-Leackage über Host-RAM

Grundsätzlich muss man sich über etwas klar sein, das unabhängig davon gilt, ob man Volume-Verschlüsselung über den Gast oder den Host betreibt: Alle (De-)Kryptierungs-Schlüssel landen irgendwo im RAM des Systems.

Im hier diskutierten Fall - Freelancer mit Laptop als Virtualisierungshost - wäre die Tatsache, dass der Host-Admin das Gastsystem einsehen und Speicherabzüge machen kann, kein primäres Problem. ( Off topic: Das ist ganz anders im Fall von Systemen, die von und bei Providern gehostet werden! Siehe:
https://security.stackexchange.com/questions/64102/vps-privacy-openvz-vs-kvm-vs-xen
https://www.ibm.com/blogs/cloud-computing/2013/07/29/how-your-data-leaks-from-a-virtual-machine/)

Dennoch ist der RAM des Laptops ein potentielles Angriffsziel zum Knacken verschlüsselter Systeme. Sein Inhalt darf im Betrieb nicht von Unbefugten ausgelesen werden; auf einem gehackten Host bietet weder die Voll-Kryptierung von Gästen noch des Hostes selbst einen hinreichenden Schutz. Ist ein Crypto-Schlüssel (des Hosts oder eines Gastsystems) erst einmal zum Angreifer gelangt, kann er nach einem Diebstahl des Laptops die kryptierten Volumes in Ruhe auslesen. Sicherheit erschöpft sich somit grundsätzlich nicht in der Verschlüsselung von Daten- oder OS-Volumes!

Die Inhalte von RAM-Bereichen der Gäste bzw. des Hosts dürfen aber auch nicht durch unachtsame Aktionen unsererseits auf unverschlüsselte Plattenbereiche des Hosts gelangen. Das führt zu Einschränkungen bei der Nutzung verschlüsselter Gastsysteme.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem der "Save"-Funktionalität

In den Fällen 2 und 3 der obigen Liste darf man den Zustand der virtuellen Maschinen (inkl. RAM !) nie auf einem unverschlüsselten Volume des Hosts speichern. Im Besonderen darf man das nicht, wenn der Laptop-Host auf SSDs operiert (s. meine letzten Post.) Grund: Der auf der Platte abgelegte RAM-Bereich des Gasts beherbergt einen oder mehrere LUKS-Master-Key(s).

Die meisten Virtualisierungssysteme (Voll-, Para-Virtualisierung; Container) bieten uns eine gut gemeinte Möglichkeit zum vollständigen Speichern des Zustands eines Gastsystems in Form einer "Save"-Funktion an. Das entspricht einer Art gezielt ausgelöster Hibernation des Gastes auf Storage-Bereichen dem Host. Diese "Save"-Funktionalität lösen etwa virtmanager/libvirt auf einem Suse-KVM-Hostautomatisch aus, wenn ein Shutdown des KVM-Host erfolgt - und seine Gastsysteme vorab nicht heruntergefahren wurden. Es kann aber sogar zeitgesteuerte Programme geben, die die Save-Funktion nach einer gewissen Zeit ohne User-Interaktion mit dem Gastsystem auslösen. Wenn der Host selbst auf unverschlüsselten Volumes operiert, wird das zu einem massiven Sicherheits-Problem. Wenn die System-Platte in diesem Zustand in die Hände eines Angreifers geraten sollte, kann er über eine Daten-Analyse den oder die Verschlüsselungs-Keys ermitteln und/oder die abgespeicherte Maschine gar in den operativen Zustand versetzen.

Mir ist es selbst schon in aus Unachtsamkeit oder in zeitkritischen Situationen passiert, dass ich mich auf die Save-Funktionalität von Virtualisierungshosts verlassen habe. Hier geht es also wieder um "Disziplin" des Anwenders. Der traue ich nicht - nicht mal bei mir selbst. Deshalb spricht der diskutierte Punkt für eine Verschlüsselung auch der Volumes des Host-Systems. Mindestens muss man sich aber darum kümmern, wohin der Zustand von Gastsystemen gespeichert wird - und entsprechende Verzeichnisse auf ein verschlüsseltes Volume verlagern, das am Host gemountet wird.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem der "Suspend"- oder Hibernate-Funktionalität des Hosts

Virtualisierungsprozesse für den Gast und zugehörige RAM-Bereich auf dem Host sind in bestimmten Situationen genauso zu sehen wie andere Prozesse/RAM-Bereiche des Hosts auch. Aus diesem Grund darf man in beiden oben unterschiedenen Fällen die Suspend- und Hibernate-Funktionalitäten des Hosts nicht benutzen, solange die verschlüsselte virtuelle Maschine noch läuft. Im Suspend-to-RAM-Zustand wird der Speicher womöglich nach einem Diebstahl über Spezialwerkzeuge zugänglich. Im schlimmsten Fall (kein Passwortschutz für den Pausenzustand) landet man nach dem Wieder-Erwecken des Systems in einer offenen virtuellen Maschine. Hibernation hatten wir bereits im letzten Post diskutiert - die dort aufgeführten Argumente gelten in gleicher Weise für Gastsysteme: Der RAM-Inhalt landet samt Verschlüsselungskeys und ggf. auch dekryptierten Daten auf unverschlüsselten Bereichen des Hosts.

Hibernate auf einen verschlüsselten (!) SWAP des Hosts ist ein sinnvoller Ansatz. Sicher ist in problematischen Situationen aber nur das Befolgen folgender Regel:

Gastsysteme sind vor jeglichem Suspend oder Hibernate des Hosts herunterzufahren.

Eine Zusammenfassung der Rahmenbedingungen für Voll-Verschlüsselung von Virtualisierungsgästen findet man übrigens unter folgendem Link:
https://security.stackexchange.com/questions/29535/full-disk-encryption-within-a-vm-how-secure-is-it

Wir landen somit erneut beim Thema "Disziplin des Anwenders". Es spricht einiges dafür, im Falle von Virtualisierung die Suspend-Funktionalität des Hosts zu deaktivieren und Hibernate nur zu nutzen, wenn die dabei genutzten (SWAP-) Volumes verschlüsselt sind.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem der Disziplin bei Datenzugriffen

In der Praxis benötigt man oft eine Kombination aus Linux- und Windows-Gastsystemen, um mit Kundendaten zu arbeiten und letztlich die Formate zu erzeugen, die die Kunden für notwendig erachten. Wählt man eine Lösung mit voll-verschlüsselten Gastsystemen, so darf man denn auch nur ausschließlich diese Gäste für den Zugriff auf und die Verarbeitung von schützenswerten Kundendaten nutzen. Das ist in der (mobilen) Praxis nicht so einfach, wie man meinen möchte. Virtualisierung ist zwar ein gutes Mittel zur organisatorischen Separierung von Arbeitsdomänen - speziell in einer servergestützten Umgebung. Aber gerade auf einem Laptop ist es verführerisch einfach, auch den "Host" (=Laptop) direkt für bestimmte Arbeiten einzusetzen. Da gilt es, nicht den Überblick verlieren und aus Bequemlichkeit unvorsichtig zu werden. Wie oft möchte man schnell mal eine Datei, die man auf dem Host herunter geladen hat, zum Gast transferieren. Oder eben umgekehrt ... Mounten von Gast-Devices am Host ist z.B. tabu, wenn man desktop-weite Suchmaschinen und Daten-Indexer am Laufen hat. Wir haben es also erneut mit dem Thema der Anwender-Disziplin zu tun ...

Zu nennen ist aber auch das Thema der Protokolle für den grafischen Zugriff auf den Gast (Spice, diverse VNCs, X2GO, ...). Zugehörige Client-Porgramme muss man auf dem Laptop (Host) ausführen; sie beherbergen oft auch eine Reihe von Komfort-Funktionen. Dann ist zu fragen: Werden wirklich keine relevanten Daten in den jeweiligen Clients unter Nutzung des Host-Storage gepuffert? Was passiert bei Copy/Paste-Aktionen? Sind Share-Optionen für den Datei-Austausch alle abgeschaltet? Der Teufel steckt hier möglicherweise im Detail des jeweiligen Protokolls - und wer kennt die schon alle ....

Ferner müssen die genutzten Gastsysteme voll netz- und internet-fähig werden - ohne dass direkte Verbindungen vom Host oder anderen unbefugten Gastsystemen zu den Gästen für die kundenbezogenen Aufgaben zugelassen werden. Das zieht sofort eine sorgfältige Dienste-Konfiguration auf dem Gast-System und komplexeres Firewalling in virtuellen Netzen nach sich - insbesondere dann, wenn man auch noch die Kommunikation zwischen Windows-Gästen und Linux-Gästen kontrollieren muss.

Es ist nicht so, dass man das nicht alles in den Griff bekommt. Aber eine Vollverschlüsselung auch des Hosts (hier des Laptops) dämpft einen Teil der Risiken.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem des Host-Swaps

SWAP-Space dient dem Abfangen von RAM-Engpässen und auch für Hibernation. Auf einem Virtualisierungs-Host - zumal einem Laptop - ist die Wahrscheinlichkeit hoch, dass der RAM knapp wird, wenn mehrere Gäste unterstützt werden müssen. Konsequenz ist, dass der SWAP des Hosts in jedem Fall verschlüsselt werden muss.

Verschlüsseltes Gastsystem, unverschlüsselter Host - das Problem von Dumps

Eine Sache, die oft übersehen wird, sind Dumps des Hosts im Fehlerfall. Auch Linux ist ja nicht gegen (seltene!) Abstürze gefeit. Auch dann würden Infos aus dem RAM ungewollt auf dem ggf. unverschlüsselten Storage des Hosts landen.

Verschlüsselung auch der Gast-Volumes dem Host überlassen?

Wir hatte weiter oben Alternativen unterschieden, bei denen der Host oder aber die Gastsysteme für die Verschlüsselung zuständig sind. Abschließend möchte ich deshalb noch kurz einen Punkt ansprechen, der in der Praxis relevant werden kann: Verschlüsselung erfordert zusätzliche CPU-Prozesse, die auf die vorhandenen CPU-Cores entweder des Hosts oder der Gäste verteilt werden müssen.

Jemand, der auf einem Laptop ernsthaft Virtualisierung betreibt, wird eine entsprechende CPU mit Hyperthreading und 4 bis 6 Standard-Cores wählen. Das entspricht dann 8 bis 12 Threads (virtuellen CPU-Cores) für die Virtualisierung. Wie man die Cores verteilt, sollte bei der Frage, ob das Gast-System oder der Host verschlüsselt, beachtet werden. Hat der Host insgesamt noch mehr Cores als die Gastsysteme selbst zur Verfügung, so erscheint es mir aus Performance-Gründen klug, die Verschlüsselung auch von Volumes, die die Gäste als Storage nutzen, gänzlich dem Host zu überlassen. Ich habe damit auf KVM-Virtualisierungsservern gute Erfahrungen gemacht.

Fazit - lieber auch den Host voll verschlüsseln

Virtualisierung kann auch auf einem professionell genutzten Laptop relevant sein. Die oben diskutierten Punkte sprechen dafür, den Virtualisierungshost( = Laptop-OS samt Storage-Volumes) neben den Gästen voll zu verschlüsseln. Man kann versuchen, alle Bereiche des Hosts zu identifizieren, die potentiell Inhalte des Gastes (RAM) in verschiedenen Situationen aufnehmen würden. Mir persönlich wäre das Risiko, dabei etwas zu übersehen, ehrlich gesagt zu groß.

Im nächsten Beitrag

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

widme ich mich der Frage, wie die verschiedenen Zugriffs-Layer eines verschlüsselten Laptops (LVM, LUKS, ggf. RAID) geschichtet werden können.