Ich widme mich in dieser der Verschlüsselung eines Laptops unter Opensuse Leap 15.0. Das ist nicht nur technisch interessant. Eine wichtige Motivation sind Auflagen, die ich als Freelancer gegenüber Auftraggebern erfüllen muss, um der DSGVO “auf dem Stand der Technik” gerecht zu werden. Da ich regelmäßig mit personenbezogenen Daten der Unternehmen konfrontiert bin, gab es hier keine Ausnahmeregelungen für KMU. Bei einer Analyse der technischen Anforderungen merkt man schnell, dass sich die Sicherheit sensibler Daten auf der Ebene der Datenhaltung nicht allein durch die Bereitstellung von verschlüsselten Containern oder einzelner Partitionen/Volumes erreichen lässt. Im letzten Beitrag

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

hatte ich daher einige Argumente für eine Voll-Verschlüsselung zusammengestellt. 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 ein gutes Mittel zur Separation von Arbeits- und Kunden-Domänen. Das betrifft einerseits eine getrennte Haltung und Bearbeitung der Daten spezifischer Kunden; es betrifft aber auch die Kommunikations- und Netzwerkfähigkeiten der kundenbezogenen Gastsyteme: Man kann die Netzwerk-Kommunikation von Gastsystemen für den kundenbezogenen Einsatz auf ganz bestimmte Server – z.B. die des Kunden – einschränken und entsprechende ausgehende und eingehende Verbindungen überwachen.

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 deutlich besser gewährleistet als bei Containern.

Voll-Virtualisierung bietet also zusätzliche Möglichkeiten, die Sicherheit der Interaktion mit Kundensystemen 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”. Das root-Filesystem kürze ich mit “/”-FS ab.

Voll-Verschlüsselung virtualisierter Gast-Systeme – Varianten

Spricht man über Virtualisierung und Verschlüsselung, so ist zwischen dem Host, den Gastsystemen 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 Zeitgenossen können natürlich auch Variante 1 und 3 kombinieren – und so zwei ineinander greifende Schichten der Verschlüsselung aufbauen. Das wird sich aber womöglich in einer Reduktion der Performance niederschlagen. Eine weitere Variante wäre die, das “/”-FS 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 ein Faktum im Klaren 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. Dieser Host-Admin ist man im Regelbetrieb ja selbst. Wegen Rückfragen einzelner Leser möchte ich aber explizit darauf hinweisen, dass das im Fall von Systemen, die von und bei Providern gehostet werden, völlig anders zu beurteilen ist! Siehe hierzu etwa:
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 Gast-Systeme.

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öst z.B. das Gespann 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 auch zeitgesteuerte Programme geben, die die Save-Funktion nach einer gewissen Zeit ohne User-Interaktion mit dem Gastsystem starten. 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 – auch nicht 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. Daraus ergeben sich zwei Regeln:

• Suspend-to-RAM [StR] ist sowohl für den Host wie die Gastsysteme zu vermeiden. Gerät der Laptop in einem StR-Zustand in die Hände von Datendieben, ist er in der Regel “nur” mit dem Problem des Knacken eines Nutzer-Passworts (Screensaver) konfrontiert. Im schlimmsten Fall (kein Passwortschutz für den Pausenzustand) landet man nach dem Wieder-Erwecken des Systems in einer offenen virtuellen Maschine. Ferner bietet sich Spezialisten die Chance, den RAM mit elektronischen Mitteln auszulesen. StR ist also u.a. für das Herunterklappen des Laptop-Schirms und Spezialtasten des Hosts zu deaktivieren!
• In beiden oben unterschiedenen Fällen darf man auch die Hibernate-Funktionalitäten des unverschlüsselten Hosts nicht benutzen, solange die verschlüsselte virtuelle Maschine noch läuft.

Hibernation für nur teilverschlüsselte Systeme hatten wir bereits im letzten Artikel diskutiert – die dort aufgeführten Argumente gelten in gleicher Weise für virtualisierte Gastsysteme: Der RAM-Inhalt der Gäste und des Hosts landet samt Verschlüsselungskeys für die Gast-Volumes und ggf. auch dekryptierten Daten der Gäste in unverschlüsselten (SWAP-) Bereichen des Hosts.

Hibernation in einen verschlüsselten (!) SWAP des Hosts ist aus meiner Sicht dagegen ein sinnvoller Ansatz.

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”; auf einem unverschlüsselten Host muss er die Gastsysteme herunterfahren und vom Host geöffnete zugehörige Krypto-Volumes schließen, bevor er Hibernation nutzt. Darauf kann man sich nicht
verlassen. Es spricht deshalb 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. Dann kann man aber auch gleich den Host selbst voll verschlüsseln.

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 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 bekommen könnte. Aber eine Voll-Verschlü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, die ein Hosts ggf. im Fehlerfall automatisch erzeugt. Auch Linux ist ja nicht gegen (seltene!) Abstürze gefeit. Auch dann würden Infos aus dem RAM womöglich 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 vernünftig, die Verschlüsselung auch von Volumes, die die Gäste als Storage nutzen, gänzlich dem Host zu überlassen. Ich selbst 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.