Bereits in meinem Artikel Docker im Entwickleralltag habe ich in einigem Detail beschrieben, wie sich für mich schon zum Ende des letzten Jahrtausends die Arbeit mit virtuellen Maschinen in der Entwicklung durchsetzt. Diese virtuellen Umgebungen stellen wirksame Kapselungseinheiten dar, die ich zunächst zu schätzen lernte, um unterschiedliche Kundenanforderungen zu erfüllen und zwischen gleichzeitig aktiven Projekten reibungslos wechseln zu können.
Im Laufe der Zeit entdeckte ich andere Vorteile meiner neuen Arbeitsweise: zum Beispiel war es nicht notwendig, in virtuellen Maschinen Virenscanner zu installieren. Das war damals bedeutsam, weil Virenscanner durchaus einige CPU-Zeit verbrauchten und auch durch den zusätzlichen Datenaustausch mit der Festplatte einen Compilerlauf verlangsamen konnten. Meine virtuellen Maschinen setzte ich allerdings immer zweckgebunden ein, installierte jeweils nur die Software, die spezifisch notwendig war, und verwendete niemals Browser in diesen Umgebungen, lud Email-Anhänge herunter, oder tat sonst irgendetwas, wodurch man sich womöglich Viren einhandeln konnte. Außerdem gab es von den VMs natürlich Backups und Snapshots, so dass selbst der theoretische Datenverlust in diesen Umgebungen wesentlich weniger bedrohlich erschien als auf einem „echten“ Entwicklersystem.
Im Laufe der Jahre wurde die Hardware eines durchschnittlichen Entwicklersystems immer leistungsfähiger. Als ich damit begann, VMs zur Entwicklung einzusetzen, benötigte man einen überdurchschnittlichen PC, um darauf Linux zu installieren und selektiv Windows-VMs laufen zu lassen. Nach einigen Jahren war es möglich, auch einmal mehrere VMs gleichzeitig laufen zu lassen, um etwa Client/Server-Anwendungen zu testen. Parallel zu diesen Erfahrungen, die ich bei Desktop-Systemen machte, entwickelte sich die VM-Technologie im Serverbereich weiter, so dass heute virtuelle Server (etwa bei Host Europe) auf Basis von VMs betrieben werden, sowie auch komplexe Cloud-Umgebungen. Auf dem Desktop wiederum bediente man sich der neuen Technologie, um eine ganz andere Architektur für ein Betriebssystem aufzubauen. So entstand Qubes OS, in eigenen Worten – bitte ironisch zu verstehen! – ein „halbwegs sicheres Betriebssystem“.
Qubes OS treibt Virtualisierung auf die Spitze
Im Jahre 2009 arbeiteten Joanna Rutkowska und Rafal Wojtczuk an einem Konzept für eine Systemarchitektur basierend auf virtuellen Maschinen. (Hier eine neuere Version des Konzepts, wenn Sie Interesse an den Details haben.) Dabei hoben sie besonders hervor, dass Desktop-Betriebssysteme im Allgemeinen kaum Mechanismen unterstützten, um laufende Programme voneinander zu isolieren. Wenn Browser Sicherheitslücken hatten, erlaubten diese oft den Zugang zum gesamten Computer mit allen laufenden Programmen sowie den Inhalten von Festplatten und Hauptspeicher. Auch Treiber, wie die für WLAN-Karten oder Bluetooth, konnten Lücken haben und somit uneingeschränkten Zugriff gewähren. Die Autoren des Konzepts waren der Auffassung, dass ein reaktiver Umgang mit Sicherheitsproblemen nicht ausreichend sei. Sie erklärten, dass ein Computeranwender damit rechnen muss, dass sein System früher oder später von Viren infiziert oder von Hackern angegriffen wird. So entstand die Idee, den potentiellen Schaden klein zu halten, indem Systemkomponenten strikt getrennt werden. In Qubes OS geschieht dies auf Basis von virtuellen Maschinen.
Die Grundlage von Qubes OS ist ein Linux-basiertes System mit dem Xen-Hypervisor. Ein Hypervisor ist die Software, die virtuelle Maschinen verwaltet, und Xen ist eine Open Source-Implementation, die sich großer Beliebtheit erfreut und noch heute in der Amazon Cloud zum Einsatz kommt. Der Hypervisor arbeitet mit dem Linux-Kernel zusammen, um mehrere virtuelle Systeme parallel laufen zu lassen und deren strikte Trennung zu garantieren. Gewöhnlich „wissen“ die einzelnen Teilnehmer an solcher Parallelisierung, in welcher Umgebung sie laufen. Xen unterstützt aber auch Hardware Virtual Machines (HVMs), in denen Gastsysteme ohne besondere Vorbereitung laufen können – etwa Microsoft Windows.
Basierend auf Xen, oder gar dem Linux-eigenen KVM-Hypervisor, kann jeder Linux-Anwender beliebig virtuelle Maschinen starten. Das besondere an Qubes OS ist, dass das Gesamtsystem mehrere Standard-VMs zu bestimmten Zwecken vorsieht. Es gibt eine Installationsroutine, die solch ein komplexes System automatisch installieren kann, und unterschiedliche Mechanismen zur Integration der VMs werden fertig mitgeliefert. So ist die Arbeit mit Qubes OS komfortabel, so dass der erhöhten Sicherheit kein drastischer Komfortverlust im Alltag gegenüber steht.
Zur Installation von Qubes OS gibt es eine detaillierte Dokumentation. Ich empfehle sehr, diese genau zu lesen! Es gibt gewisse Anforderungen an ein System, damit die Virtualisierung korrekt funktioniert. Ich selbst habe Qubes OS auf einigen unterschiedlichen Systemen erfolgreich installiert, sowohl auf selbst gebauten Desktopsystemen als auf auch Laptops. Generell sollten Sie vorzugsweise Hardware verwenden, die von Standard-Linux-Kerneln unterstützt wird. Auf der Webseite gibt es eine Liste mit Hardware-Infos (Hardware Compatibility List), wo Sie eventuell nützliche Hinweise finden.
Qubes sind Bausteine für das System
Bereits während der Installation finden sich Hinweise darauf, dass mehrere unterschiedliche VMs für das System aufgesetzt werden. In Qubes OS werden die einzelnen VMs gewöhnlich „Qubes“ genannt, und es gibt mehrere, die vom System selbst genutzt werden. „dom0“ ist eine spezielle Umgebung, von der aus der Zugang zu Xen möglich ist, und somit die Verwaltung der anderen VMs. „sys-usb“ ist eine VM, die direkt mit USB-Geräten kommuniziert. Von dort können USB-Geräte selektiv mit anderen VMs gekoppelt werden, während die USB-Treiber in einer gekapselten Umgebung laufen, so dass die Angriffsfläche bei einem Sicherheitsfehler im USB-Treiber möglichst klein bleibt. „sys-net“ ist für Netzwerkschnittstellen zuständig, und dies ist noch einmal getrennt von „sys-firewall“, wo eine Firewall implementiert ist. Für das System Whonix, eine Linux-Distribution mit eingebauter Tor-Unterstützung, gibt es weitere Standard-VMs, so dass in Qubes OS die Verwendung dedizierter Tor-Umgebungen oder auch das Routen sämtlichen Netzwerkverkehrs durch Tor sehr einfach möglich ist – während alle einzelnen Komponenten eines solchen Setups voneinander vollständig getrennt bleiben! Etwaige Eindringlinge fänden sich hypothetisch jeweils nur in einer kleinen virtuellen Systemumgebung wieder, je nach der Software-Komponente, die sie gehackt haben. Letztlich basiert die Sicherheit der Kapselung selbst auf Xen. Dieses Projekt hat wie jede andere Software gelegentlich Bugs, aber aufgrund seiner verbreiteten Verwendung und der Aufmerksamkeit des Qubes-Entwicklerteams gab es bisher sehr selten Grund zur Sorge.
Der Qube Manager zeigt den Status aller VMs auf dem System
Die VMs, in denen ich als Systemanwender letztlich arbeite, sind durch ein Template-System noch zusätzlich geschützt. Zum Beispiel gibt es in meinen Qubes-Installationen jeweils eine VM namens „dev“, in der ich allgemeine Entwicklungsarbeit leiste. Eine VM, in der mit Anwendungen gearbeitet wird, bezeichnet man als „App VM“, und sie basiert auf einer „Template VM“. Für mein Setup habe ich den Weg gewählt, eine Template VM extra für „dev“ zu bauen. Darin habe ich alle Software installiert, die ich nachher in „dev“ benötige. Wenn ich in „dev“ selbst weitere Software installiere – oder, falls ich ein Bösewicht sein sollte, ich anderweitig Änderungen an der Systemumgebung durchführe – werden diese Änderungen beim nächsten Neustart von „dev“ wieder rückgängig gemacht, da die Template VM sich nicht geändert hat. Persistent ist lediglich der Datenbereich, in dem Nutzerdaten abgelegt werden. Die Daten im System, die etwa installierte Anwendungen oder Systemdateien enthalten, sind nur von der Template VM aus änderbar.
Strikte Trennung sorgt für Sicherheit
Basierend auf diesem Konzept gibt es eine weitere wichtige Art der VM in Qubes OS: die „Disp VM“, kurz für „disposable“, also wegwerfbar. Diese VM unterscheidet sich von der App VM dadurch, dass sie keinen persistenten Datenbereich hat. Mit anderen Worten, jegliche Änderungen in einer solchen VM werden automatisch verworfen, sobald die VM beendet wird. Dies lässt sich nutzen, um zusätzliche Kapselung zu erzeugen. Zum Beispiel verwende ich eine VM „sensitive“, in der ich auf meine Email zugreife. Diese VM ist bereits vom restlichen System getrennt, weil mir Email besonders wichtig ist und nicht versehentlich durch ein Browserplugin in meiner VM „untrusted“ an die Öffentlichkeit gelangen soll („untrusted“ ist die VM, in der ich die meisten Webseiten browse, bei denen ich mich nicht extra einlogge).
Wenn ich nun in „sensitive“ allerdings eine E-Mail mit einem Anhang empfange, den ich mir gern ansehen möchte, dann will ich das ungern in dieser VM direkt tun. Der Anhang könnte schließlich einen Virus enthalten! An dieser Stelle kommt die „Disp VM“ zum Einsatz: ich öffne einfach eine Disp VM, übergebe die Datei aus dem Mailanhang, so dass diese dann in einer temporären Instanz der Disp VM geöffnet wird. Nachdem ich damit fertig bin, schliesse ich die Anwendung, mit der die Datei geöffnet wurde – etwa Libre Office –, die Disp VM beendet sich und alle Daten aus dieser VM werden verworfen. Meine Email ist die ganze Zeit über sicher in ihrer eigenen VM aufgehoben. Während der Arbeit mit Anwendungen hilft übrigens die Farbgebung der Fenster in der UI mit, die Zugehörigkeit zu VMs im Kopf zu behalten. Jeder VM ist eine Farbe zugeordnet, und alle Fenster der VM verwenden diese Farbe – so lassen sich leicht Schemas etablieren wie „nur in grünen VMs mit Passwörtern arbeiten“.
Integration im Dateimanager und in Apps wie Thunderbird vereinfacht den Umgang mit Disp VMs
Nun mögen Sie bemerkt haben, dass ich vorhin den Vorgang, einen Email-Anhang in einer Disp VM zu öffnen, als „einfach“ bezeichnet habe. Verständlicherweise erscheint solch ein Vorgang nicht unmittelbar „einfach“, wenn Sie noch nie mit Qubes OS gearbeitet haben! Tatsächlich kommt an dieser Stelle allerdings ein Qubes OS Integrationsfeature zum Tragen – es handelt sich bei diesem System eben um viel mehr als nur die Summe mehrerer VMs! So wird zum Öffnen einer Datei in einer Disp VM wirklich nur ein Kommando benötigt, und es gibt auch fertige Integration mit Thunderbird, so dass dort ein Email-Anhang mit einem einfachen Mausklick im Kontextmenü in einer Disp VM geöffnet werden kann. Auch für den Dateimanager gibt es eine solche Integration, und abgesehen vom risikofreien Öffnen der Datei ist es auch möglich, diese eine Datei in einer Disp VM zu ändern, ohne dabei andere Dateien zu gefährden.
Ähnlich nützlich ist das System zum Austausch von Clipboard-Inhalten. Grundsätzlich hat jede VM ihr eigenes Clipboard, so dass copy/paste-Daten nie automatisch mit anderen VMs geteilt werden. Allerdings kann per globaler Tastenkombination jederzeit der Clipboard-Inhalt aus einer VM in einen globalen Zwischenbereich übertragen werden. Mit einer anderen Tastenkombination wird der Inhalt dann in eine Ziel-VM übernommen, während der globale Bereich wieder geleert wird, im Missbrauch zu vermeiden.
Ein Clipboard-Manager koordiniert den Austausch von Daten zwischen VMs
Eine weitere wichtige Funktion wird mithilfe eines Tray-Icons sehr einfach nutzbar: die Anbindung von USB- und anderen dynamischen Geräten im System. Wenn ich etwa einen USB-Stick einstecke, zeigt dieses Icon in seinem Menü Namen oder Typnamen des Sticks an. Ich kann direkt dort auswählen, an welche laufende VM der Stick angeschlossen werden soll. Natürlich ist dies ein zusätzlicher Schritt im Vergleich zum Betrieb ohne Qubes OS, aber ich gewinne dadurch Sicherheit, denn ein neu angeschlossenes Gerät kann niemals automatisch von einem laufenden Prozess angesprochen werden, ohne dass ich das explizit entscheide.
USB-Geräte werden explizit mit VMs verbunden
Alle in Qubes OS implementierten Integrationsfunktionen sind über die Kommandozeile ausführbar. Mit einiger Übung verwendet man recht flüssig einige der Xen-Kommandos für alltägliche Aufgaben, und die Kommandos for Qubes OS selbst lassen sich so auch in Skripte einbauen oder als Teil eigener Automatisierungen nutzen. Zum Abschluss dieser kurzen Übersicht möchte ich noch einen Fall beschreiben, zu dem die Modifikation der Netzwerkkonfiguration des Systems sinnvoll ist. Die Lösung ist nicht unkompliziert, und kann wahlweise verstanden werden, um entweder die Flexibilität von Qubes OS zu belegen oder um aufzuzeigen, dass die zusätzliche Sicherheit auch mit Kosten daher kommt.
Qubes OS kann auch Windows
Die Problemstellung war, eine Windows-VM im Qubes OS System einzurichten. Grundsätzlich ist das ganz einfach: eine neue VM erzeugen und als HVM einrichten, dann Windows von einem ISO-Image installieren. Soweit geht das alles beinahe von selbst, aber nun gibt es einige Hürden, denn die HVM ist nicht im selben Maße in Qubes OS integriert wie die Standard-VMs. Es gibt ein Paket namens „qubes-windows-tools„, das einige Treiber für Windows auf Qubes-Basis enthält, aber damit gibt es bei aktuellen Windows-Versionen eventuell Kompatibilitätsprobleme. Daher entschied ich mich, per Remote Desktop auf die Windows-VM zuzugreifen. Das funktioniert zum Beispiel mit xfreerdp von Linux aus, so dass das Zusammenspiel mit meiner „dev“-VM angenehm einfach ist. Das Problem ist nur, dass unter Qubes OS normalerweise alle VMs voneinander isoliert sind. Um also aus der VM „dev“ mit xfreerdp auf die VM „win10“ zugreifen zu können, musste ich einen Eintrag für die Firewall hinzufügen.
Auf meinem Qubes-System (wie Sie einem der vorherigen Bilder entnehmen können) hat die VM „dev“ die IP-Adresse 10.137.0.18, während „win10“ die 10.137.0.20 hat. Dies sind Adressen, die lediglich innerhalb des lokalen Systems relevant sind! Beide VMs sind so konfiguriert, dass sie „sys-firewall“ als Netzwerk-Gateway verwenden. In „sys-firewall“ änderte ich also die Datei /rw/config/qubes-firewall-user-script und fügte folgende Zeile hinzu:
iptables -I FORWARD 2 -s 10.137.0.18 -d 10.137.0.20 -j ACCEPT
Solche Techniken sind übrigens keine Geheimnisse – die Dokumentation von Qubes OS enthält Details und Beispiele dazu. Bei meinem ersten Versuch, eine solche Konfiguration zu aktivieren, brauchte ich einige Zeit, um die Details zu verstehen bzw. mir bildlich vorzustellen, wie eine VM im System mit einer anderen „redet“, auf dem Weg über die Firewall. Allerdings stellte sich diese Erfahrung letztlich als nützlich heraus, da ich auch zu anderen Zwecken seitdem Änderungen an der Firewall-Konfiguration durchgeführt habe.
Fazit
Ich hoffe, dass Ihnen die Beschreibung von Qubes OS interessant erscheint und Sie sich das System einmal näher ansehen! Meiner Ansicht nach ist die zusätzliche Sicherheit, die sich durch die starke Modularisierung des Systems ergibt, durchaus den recht kleinen Mehraufwand bei manchen alltäglichen Aufgaben wert. In vieler Hinsicht ist die Verwendung von Qubes OS tatsächlich sehr angenehm, da die logische Trennung von Aufgabenstellungen erzwungen wird und man sich so als Anwender weniger Sorgen machen muss, dass man selbst versehentlich Schaden anrichtet. Wir Entwickler sind schließlich sehr fortgeschrittene Anwender, wir setzen viel unterschiedliche Software täglich ein, und diese Software greift oft sehr tief ins System ein, arbeitet mit vielen Daten, und ist somit besonders anfällig für Sicherheitsprobleme. Mit Qubes OS ist das Risiko wesentlich kleiner!
- Eine Docker-Anwendung auf einem Virtual Ubuntu-Server von Host Europe betreiben – Teil 2 - 4. November 2022
- Eine Docker-Anwendung auf einem Virtual Ubuntu-Server von Host Europe betreiben – Teil 1 - 19. Oktober 2022
- Vorbereitung eines Anwendungssystems für ein Deployment mit Docker – Tutorial - 19. Mai 2022
