Qubes OS ist ein Betriebssystem, das mit Hilfe von Virtualisierung starke Sicherheitsgewährleistungen bieten will. In der Vergangenheit hat Rocco Gagliardi das System bei uns erstmalig erkundet und seine Befunde geschildert.

Im Rahmen meiner Arbeitstätigkeit benötige ich für Penetration Tests ein sehr freies System, bevorzuge aber zum Schreiben von Reports und dem Handhaben von Kundendaten ein stark abgesichertes System. Deshalb spielte ich mit dem Gedanken ob es möglich wäre mein Arbeitssystem auf Qubes OS zu wechseln, in der Hoffnung diese beiden Qualitäten auf einem Arbeitsgerät zu vereinen. Auch alle anderen Features, die Qubes OS bringt, sind verlockend. Dazu gehören die starken Sicherheitsgewährleistungen des Xen-Bare-Metal-Hypervisors und die Flexibilität, die sich aus der Systemarchitektur heraus ergibt. So kann man eine Vielzahl von Betriebssystemen nebeneinander laufen lassen, wobei Qubes die Tools und UI zur Verfügung stellt, um diese in funktionierende Workflows zu integrieren.

Qubes OS

Qubes Feature-Highlight

Qubes hat ein Konzept sogenannter TemplateVMs. Diese VMs fungieren als Template für andere virtuelle Maschinen, welche AppVMs heissen. Eine AppVM erbt das Dateisystem ihrer TemplateVM, kann jedoch nichts auf das Template speichern. Technisch verwendet die AppVM das Dateisystem des Templates gewöhnlich und es gibt keinen Unterschied zu einer VM, die ein eigenes Dateisystem hat. Allerdings wird bei Schreibvorgängen in einen temporären CoW-Buffer geschrieben, welcher beim Abschalten der AppVM gelöscht wird. Dieser Ansatz macht es möglich, dass die AppVM das Dateisystem normal verwenden kann, ohne dass spezielle Treiber nötig sind, oder der AppVM vertraut werden muss, nichts am Template zu verändern.

Dieses einfache Konzept kann signifikante Sicherheitsgewinne ermöglichen. Man kann beispielsweise in einem ersten Schritt ein Windows-Image härten und nach Wunsch konfigurieren. Danach erstellt man eine AppVM auf Basis des Windows-Image als Template. Wenn man nun eine Applikation starten will, startet man sie stets in der AppVM. Das hat den Vorteil, dass man bei jedem Systemstart das makellose, frisch installierte Template benutzt. Es ist unmöglich, sein System von der AppVM aus über einen Neustart hinweg zu zerschiessen. Auch wenn das Windows-System im Laufe des Gebrauchs komplett kompromittiert wird und sich Malware im tiefsten Inneren des Betriebssystems einnistet, ist die AppVM nach einem Neustart wieder rein. Dies in Kombination mit der Verwendung separater AppVMs für vereinzelte Applikationen oder Applikationen mit unterschiedlichen Sicherheitsanforderungen, kann zu einer sehr soliden Sicherheitsarchitektur beitragen.

Eine AppVM kann Daten an explizit freigeschaltete Orte auf dem Dateisystem schreiben. Allerdings wird auch hier nichts auf das Template geschrieben, sondern in separatem Speicher der AppVM abgelegt. So wird oft das Home-Verzeichnis zum Schreiben freigegeben, um Applikationsdaten und Einstellungen beizubehalten. Es ist gute Praxis, nur die Lokationen zum Schreiben freizugeben, welche die AppVM benötigt. So kann beispielsweise erwägt werden, eine AppVM für Microsoft Word nur auf Documents\, AppData\Local\Microsoft\ und AppData\Roaming\Microsoft\Word\ zugreifen zu lassen.

Qubes in Enterprise-Umgebungen

Ein System wie Qubes OS hat grundsätzlich das Potenzial, in zwei Bereichen Verbesserungen zu bieten, nämlich bei der Client-Sicherheit und den gleichzeitig gewonnenen Möglichkeiten von Mitarbeitern.

Praktisch jeder wird sich im Rahmen seiner beruflichen Tätigkeit in Situationen mit verschiedenen Sicherheitsanforderungen wiederfinden. Alle diese Tätigkeiten werden auf monolithischen Systemen wie Linux und Windows auf demselben System gehandhabt, oder vom selben System aus kontrolliert. Dasselbe Client-System, das auf die wenig vertraute Chat-Applikation im Internet zugreift, spricht sensitive Entwicklungs- und Produktionsumgebungen an, besucht Links in Emails, führt einen hochvertrauten Passwort-Manager aus und öffnet routinemässig Dateien komplexer Dateiformate von Mitarbeitern und Externen. Getrennt werden sollen alle diese Prozesse vom Betriebssystem. Die abzusichernde Angriffsfläche, sowohl für Betriebssystem-Entwickler als auch konfigurativ für Systemadministratoren ist gewaltig. Hier kann ein System wie Qubes OS mit seiner Architektur punkten. Aufgaben mit verschiedenen Sicherheitsanforderungen können in verschiedenen virtuellen Maschinen voneinander getrennt werden. Virtuelle Maschinen, die für hochvertraute Tätigkeiten vorgesehen sind, können stark abgeriegelt sein, ohne andere Tätigkeiten, denen man nachgehen muss zu beeinträchtigen. Zum Beispiel soll auf der HR-VM nur auf das Mitarbeiterverwaltungssystem zugegriffen werden können. Der Grossteil der anderen Applikationen kann deinstalliert und sämtliche anderen Internetzugriffe können gänzlich blockiert werden. Massnahmen, die auf einem monolithischen System undenkbar sind.

Im Absicherungsmodell von Client-Systemen sind die Einschränkung von Möglichkeiten eines Angreifers auf dem Client und Monitoring wichtige Werkzeuge, um an die geforderte Sicherheit heranzukommen. Moderne Client-Systeme in Unternehmen sind deshalb oft stark abgeriegelt. So lautet aus Sicherheitsperspektive oft die Empfehlung. Mehr Freiheit für Endbenutzer geht meist mit grösseren Risiken einher. Das starke Absichern von Client-Systemen geht jedoch zulasten der Benutzbarkeit. Mitarbeiter können sich oft nur in einem kleinen erlaubten Rahmen bewegen. Je nach Anforderungen der ausgeübten Tätigkeit ist dies hinderlich und geht zulasten der Produktivität und der Mitarbeiterzufriedenheit. Virtualisierung hat das Potenzial, einen hohen Grad an Sicherheit zu bieten, ohne derart drastische Einschränkungen vornehmen zu müssen. Beispielsweise können fremde Applikationen installiert und verwendet werden, ohne die Daten einer unverwandten, hochvertrauten Applikation auf demselben Client zu gefährden, oder ohne diesen Zugriff auf das interne Firmennetzwerk zu geben.

Nutzungstests

Eine Anforderung für das Arbeitsgerät ist, dass aktuelle Linux und Windows-Systeme ausgeführt werden können. Das Windows-System muss in ein Active Directory (AD) integriert werden können und die Applikationen der Microsoft Office-Suite müssen benutzbar sein. Mikrophon und USB-Geräte müssen ebenfalls funktionieren.

Positives

Auf der positiven Seite konnte festgestellt werden, dass die UI-Integration von Linux und Windows-Systemen sehr gut ist. Qubes bietet die Möglichkeit, einzelne Applikationen, die in einer VM laufen in eigenen Fenstern darzustellen, als liefen sie Nativ auf einem monolithischen Betriebssystem.

Wenn man möchte, kann man auch auf die komplette Desktop-Umgebung einer VM zugreifen, so wie man virtualisierte Systeme normalerweise kennt. Die Performanz ist bei Linux-Systemen nicht von nativen Systemen zu unterscheiden. Bei Windows-Systemen liess sich ein geringer Unterschied im UI-Ansprechverhalten feststellen. Wie erwartet, gab es keine software-spezifischen Limitationen innerhalb virtualisierter Systeme und auch der gesamte virtualisierte Netzwerk-Stack liess keine Wünsche offen.

Limitationen

Die Verwendung von AppVMs beisst sich mit der Integration eines Windows-Systems in einem AD und konnte im Rahmen von Nutzungstests nicht zum Laufen gebracht werden. Zudem war festzustellen, dass es keine einfache Möglichkeit gibt USB-Devices an Windows-VMs durchzureichen. Die einzige Möglichkeit, die ich eruieren konnte, ist es den kompletten USB-Controller als PCI-Device für Windows zugänglich zu machen. Werden in der Windows-VM USB-Geräte benötigt, müssen sowohl die Windows-VM als auch die VM, welche momentan den USB-Controller hat, heruntergefahren werden, bevor Kontrolle über das PCI-Gerät gewechselt werden kann. Die Anforderung, VMs vorher herunterzufahren kann während andauernden Arbeitsabläufen natürlich ungünstig sein. Da der komplette USB-Controller herumgeschoben wird, werden alle bereits durchgereichten USB-Geräte entfernt und keine andere VM kann USB-Geräte verwenden. Dieser Prozess kann mit einem simplen Skript ein Stück weit automatisiert werden und demonstriert die praktischen Management-Programme, die Qubes zur Verfügung stellt. Leider schmälert das die Unannehmlichkeiten hier kaum. Das Skript wird in der Management-VM dom0 ausgeführt. Die hier verwendete Device-ID 00_14.0 kann natürlich variieren.

#!/bin/bash

qvm-shutdown --wait $1
qvm-shutdown --wait $2
qvm-pci detach $1 dom0:00_14.0
qvm-pci attach $2 dom0:00_14.0
qvm-start $1
qvm-start $2
echo "assigned usb controller from ${1@Q} to ${2@Q}"

Windows-VMs können ebenfalls keinen Ton abspielen oder aufnehmen. Das kann mit USB-Geräten für die Audio Ein- und Ausgabe umgangen werden. USB-Geräte mit Windows-VMs können jedoch wie erwähnt unpraktisch sein.

Fazit

Das Vorantreiben der Windows-Integration ist zum momentanen Zeitpunkt keine Priorität für das kleine Qubes Team. Die geringe Nachfrage nach entsprechenden Features zeigt, dass Windows in vielen Techniker-Kreisen eine vernachlässigbare Rolle spielt, und diese sind die primären Anwender von Qubes. Allerdings spielt Windows in der Welt vieler nicht-informatikzentrierter oder grosser Unternehmen und in denen, die diesen nahestehen, noch immer eine signifikante Rolle. Qubes OS kann die beiden Welten leider nicht reibungslos miteinander vereinen.

Die Verwendung einer Virtualisierungslösung auf dem Client, wie sie Qubes bietet, hat signifikantes Potenzial für Enterprise-Client-Deployments. Einzelne Industrien, spezifisch die Automobil-Industrie, wo Sicherheitslücken in Fahrzeugen verheerend sein können, haben die Vorteile solcher Lösung bereits erkannt. Moderne Infotainment-Systeme führen verschiedene Komponenten mit unterschiedlichen Sicherheitsanforderungen zusammen. So sollen zum Beispiel die Fahrzeugbremsen nicht durch Schwachstellen im Bluetooth-System beeinträchtigt werden. Hier spielt Virtualisierung eine Schlüsselrolle und wird von der Industrie in Projekten wie Automotive Grade Linux aktiv vorangetrieben. Dass das Qubes-Projekt diese Technik-Lücke für die Enterprise-Welt füllt, sehe ich aufgrund der momentanen Entwicklung und ihrer bekanntgegebenen mittelfristigen Ziele als wenig wahrscheinlich an.

Über den Autor

Ahmet Hrnjadovic arbeitet seit dem Jahr 2017 im Bereich Cybersecurity, wobei er sich auf die Bereiche Linux, sichere Programmierung und Web Application Security Testing fokussiert. (ORCID 0000-0003-1320-8655)

Links

• https://groups.google.com/g/qubes-devel/c/mTZjx03Zu8s/m/b830ZHuYAQAJ
• https://www.automotivelinux.org/
• https://www.qubes-os.org/