Qubes OS: Hochsicherheits-Desktop für Menschen mit hohen Sicherheitsanforderungen

Wenn Sie sich im Netz aufmerksam bewegen, kennen Sie die Klassiker: Phishing-Mails, schadhafte Anhänge, infizierte Downloads, Exploits im Browser oder im PDF-Viewer. Auf einem typischen Desktop läuft trotzdem alles unter dem gleichen User: Browser, SSH-Schlüssel, Passwortmanager, Crypto-Wallets, VPN-Profile, E-Mail-Client und Chat.

Ein einziger Klick auf den falschen Link – oder ein zu spät eingespieltes Sicherheits-Update einer Anwendung oder des Betriebssystems – kann ausreichen, um den kompletten Rechner zu kompromittieren, inklusive all dieser Zugänge.

Qubes OS setzt genau hier an: Es ist ein Hochsicherheits-Betriebssystem, das durch Isolation der einzelnen Anwendungen in eigenen Xen-VMs, den sogenannten „Qubes“, kompromittierte Anwendungen von gesunden trennt. Ziel ist, Angriffe so einzugrenzen, dass ein erfolgreicher Angriff nur die kompromittierte Anwendung selbst, aber nicht andere Anwendungen betrifft.

In diesem Artikel geht es darum, wie Qubes OS dieses Ziel technisch umsetzt, wie ein Hochsicherheits-Desktop unter Qubes aussehen kann, welche Rolle Netzwerk-Isolation, dom0, TemplateVMs, AppVMs und Disposable-VMs spielen und für wen sich dieser Ansatz lohnt.

Klassische Desktops: alles in einem Kontext

Auf einem üblichen Linux-, Windows- oder macOS-Desktop läuft der Großteil der Anwendungen im selben Benutzerkontext. Der Browser, der E-Mail-Client, SSH-Tools, Passwortmanager und Crypto-Wallets teilen sich in der Praxis denselben Adressraum, dieselben Berechtigungen und denselben Satz an Hintergrunddiensten.

Wenn ein Exploit im Browser oder im PDF-Viewer ausgenutzt wird, landet der Angreifer in genau diesem Kontext. Von dort aus kann er – je nach Systemkonfiguration – auf Ihre Dateien zugreifen, SSH-Schlüssel stehlen oder den Passwortmanager angreifen.

Natürlich gibt es auch auf klassischen Systemen Schutzmechanismen: Benutzerrechte, Sandboxing, teilweise Container. Sie ändern aber nichts an der grundlegenden Situation: Es handelt sich immer noch um ein System, in dem sehr viele kritische Anwendungen im selben logischen Bereich laufen.

Qubes OS verfolgt einen anderen Ansatz und trennt konsequent in viele voneinander isolierte virtuelle Maschinen, die jeweils nur für einen eng abgegrenzten Zweck zuständig sind.

Grundprinzip von Qubes OS: Kompartimentierung mit Xen

Unter Qubes OS läuft kein einzelnes Betriebssystem, sondern eine Sammlung von virtuellen Maschinen, die jeweils einen bestimmten Zweck erfüllen. Jede Anwendung oder Anwendungsgruppe wird in eine eigene VM gelegt – einen Qube.

Auf der untersten Ebene läuft der Xen-Hypervisor, der die virtuellen Maschinen hostet, in denen die Qubes laufen – derselbe Hypervisor, auf den auch große Cloud-Provider seit vielen Jahren für die Isolation von Cloud-Servern setzen. Eine kompromittierter Qube-VM kann nicht einfach beliebigen Dateien anderer Qube-VMs lesen oder deren Festplatten direkt ansprechen. Dafür wären komplexe, hochspezialisierte Hypervisor-Exploits nötig, wie man sie typischerweise im Werkzeugkasten von staatlichen Akteuren findet.

Wichtig ist: Ein Angriff auf den Browser bedeutet unter Qubes OS zunächst nur, dass lediglich die VM betroffen ist, in der dieser Browser läuft. Wenn in dieser VM ausschließlich dieser Browser und die zugehörigen Daten existieren, kann der Angreifer auch nur genau diese Daten einsehen und diesen Browser manipulieren. Er sieht weder die SSH-Schlüssel in einem separaten Admin-Qube noch Ihre offline-Crypto-Wallets in dedizierten Qubes.

Hochsicherheits-Desktop unter Qubes OS – ein Beispiel

Ein frisches Qubes-OS-System bringt bereits ein vorkonfiguriertes Set an Qubes mit. Typischerweise gibt es einen Qube für private Nutzung, einen Qube für Arbeit, einen unprivilegierten Qube für unsichere Webseiten, einen Qube ohne Netzwerk für besonders sensible Daten sowie mehrere System-Qubes für Netzwerk und USB.

Dieses Standard-Setup lässt sich beliebig erweitern und anpassen. Mit ausreichend Hardware-Ressourcen ist es problemlos möglich, jede einzelne Anwendung in einen eigenen Qube zu legen, so dass etwa jeder SSH-Zugang, jeder Browser-Kontext oder jedes Admin-Tool in einer eigenen VM läuft.

Gerade Experten für Hochsicherheits-Hostingumgebungen setzen Qubes OS in dieser Form ein: Jede Anwendung läuft in einem eigenen Qube, SSH-Zugänge, Kunden-VPNs, Admin-Terminals, Browser-Fenster für Monitoring-Dashboards und Chat-Clients werden strikt voneinander getrennt. Wird eine Anwendung kompromittiert, bleibt der Schaden zuverlässig auf den betroffenen Qube begrenzt.

Neben den Anwendungs-Qubes existieren Netzwerk-Qubes wie zum Beispiel sys-net, sys-firewall und sys-usb. Diese sind dafür zuständig, den Zugriff auf physische Netzwerk- und USB-Hardware zu kapseln und so vom eigentlichen Arbeits-Desktop zu trennen – dazu später mehr.

Datenfluss zwischen Qubes: Beispiel „Kontoauszüge aus dem Banking-Browser im Office-Dokumente-Qube speichern“

Eine naheliegende Frage lautet: Wie gelangt beispielsweise ein im „trusted Banking-Browser“ heruntergeladener Kontoauszug als PDF in einen offline Qube, in dem Office-Dokumente bearbeitet werden, ohne dass dabei die Grundidee der Isolation verloren geht?

Qubes OS löst das, indem Kopiervorgänge zwar technisch von einer VM in eine andere übertragen werden, aber jeder einzelne Transfer in dom0 explizit per Klick bestätigt werden muss. dom0 ist die Verwaltungs-VM, in der auch der X-Server (Fenster- und Display-Server des Desktops) läuft, der die Fenster der einzelnen VMs auf den Bildschirm zeichnet. dom0 hat keinen Netzwerkzugang und ist strikt von den Anwendungs-VMs isoliert.

Wenn Sie in einem Qube eine Datei in einen anderen Qube kopieren möchten, geschieht das über intuitive Kontextmenüs. Sie klicken beispielsweise mit der rechten Maustaste auf die Datei und wählen „Copy to VM…“. Daraufhin erscheint in dom0 ein Dialogfenster, in dem Sie explizit bestätigen, dass diese eine Datei aus dem Banking-Qube in den Office-Dokumente-Qube übertragen werden darf.

Eine kompromittierte VM kann also nicht heimlich Dateien in andere Qubes kopieren oder abziehen. Jeder Kopiervorgang muss explizit in dom0 bestätigt werden. Genau dieses Muster zieht sich durch den gesamten Datenfluss: Text, Dateien und andere Inhalte wechseln nur dann den Qube, wenn der Benutzer in der Vertrauensebene von dom0 zustimmt.

Damit bleibt es technisch überschaubar, sensible Daten in einem hoch vertrauenswürdigen Qube zu halten und nur in streng kontrollierten Einzelfällen in andere Qubes zu übertragen.

Netzwerk-Isolation: sys-net, sys-firewall, sys-vpn und Whonix

Neben der Trennung der Anwendungen spielt die Netzwerk-Architektur eine zentrale Rolle. Qubes OS trennt Netzwerkzugriff in mehrere Schichten.

Die physische Netzwerkkarte ist typischerweise ausschließlich an einen Qube sys-net angebunden. sys-net ist der einzige Qube, der direkten Zugriff auf WLAN- oder Ethernet-Hardware hat. Alle anderen Qubes sehen von der eigentlichen Hardware nichts.

Über sys-net hängt häufig ein weiterer Qube sys-firewall, der für die Paketfilterung zuständig ist. Dort lässt sich sehr granular konfigurieren, welche Anwendungs-Qubes welche Ziele erreichen dürfen. Ein Mail-Qube könnte beispielsweise so konfiguriert werden, dass er ausschließlich ausgehende TCP-Verbindungen zu den IMAP- und SMTP-Servern von gmail.com aufbauen darf und sonst nichts. Andere Qubes dürfen vielleicht nur HTTP/HTTPS-Verbindungen zu bestimmten Websites aufbauen, etwa dem Online-Banking-Portal der eigenen Bank. So lässt sich verhindern, dass ein Klick auf einen Link in einer Phishing-E-Mail unbemerkt zu einem gefälschten Banking-Portal führt.

Vor oder hinter sys-firewall kann ein zusätzlicher Qube sys-vpn eingefügt werden, über den bestimmte Qubes ihren gesamten Traffic durch ein VPN schicken. Wenn ein Anwendungs-Qube so konfiguriert ist, dass er nur über sys-vpn ins Netz darf, dann sieht sys-net – selbst im Fall einer Kompromittierung – nur noch VPN-Tunnelverkehr und keine Klartext-Verbindungen mehr.

Für anonymes Surfen im Internet kann ein Whonix-Gateway als weiteres Netz-Qube eingebunden werden. In einem solchen Setup hat die eigentliche Anwendungs-VM keinen direkten Zugang zum Netz, sondern schickt all ihren Verkehr an das Whonix-Gateway, das den Traffic durch das Tor-Netzwerk weiterleitet. Auch hier greifen wieder die gleichen Trennungsmechanismen: Ein erfolgreicher Angriff auf eine Anwendungs-VM bedeutet noch nicht, dass damit die darunterliegenden Netzwerk-Qubes oder dom0 kompromittiert sind.

Durch diese Schichtung werden Netzwerk-Angriffe zusätzlich segmentiert. Ein Angriff auf sys-net sieht nur das, was auf dieser Ebene passiert (zum Beispiel VPN-Traffic), ein Angriff auf einen Anwendungs-Qube sieht nur dessen eigene Verbindungen, und dom0 bleibt ohne direkten Netz-Zugriff vollständig außen vor.

dom0, TemplateVMs, AppVMs und Disposable-VMs

Die Isolation in Qubes OS beruht nicht nur auf der Trennung der Anwendungen und Netzwege, sondern auch auf einer klaren Struktur der verschiedenen VM-Typen.

dom0 ist die Verwaltungs-VM, in der der X-Server (Fenster- und Display-Server des Desktops) läuft und in der Sie die Fenster der anderen Qubes sehen. dom0 verwaltet das Starten und Stoppen der VMs, die Konfiguration und die zentralen Einstellungen. Gleichzeitig ist dom0 vollständig vom Netzwerk getrennt, führt keine normalen Anwendungen wie Browser oder E-Mail-Clients aus und ist damit deutlich weniger angreifbar als ein klassischer Desktop.

Die eigentlichen Betriebssystem-Installationen liegen in TemplateVMs. Eine TemplateVM enthält das Root-Dateisystem eines Linux-Systems, inklusive aller installierten Pakete und Systembibliotheken. AppVMs, also die Qubes, in denen Sie tatsächlich arbeiten, starten nicht direkt ihr eigenes Root-Dateisystem, sondern verwenden beim Start einen Clone des Template-Root-Filesystems. Dieser Clone ist beschreibbar, wird aber beim Herunterfahren der AppVM verworfen.

Das bedeutet: Wenn in einer AppVM das Systemverzeichnis manipuliert wird, bleiben diese Änderungen auf diese AppVM beschränkt und überleben einen Neustart nicht. Die TemplateVM selbst wird dadurch nicht verändert.

Persistente Daten wie Konfigurationen und Dokumente liegen in einem separaten Volume der AppVM. Konkret ist in AppVMs das Verzeichnis /home persistent und bleibt über Neustarts hinweg erhalten, während der Rest des Systems aus dem bei jedem Start neu erzeugten Clone der TemplateVM stammt und beim Herunterfahren verworfen wird. Dadurch können Sie einerseits zentral Updates in der TemplateVM einspielen und andererseits sicher sein, dass kompromittierende Änderungen am Systemteil einer AppVM nicht dauerhaft im System bleiben.

Für besonders kurzlebige oder riskante Aufgaben gibt es Disposable-VMs. Diese werden bei Bedarf aus einem Template erzeugt, erhalten ein eigenes, bei Bedarf erzeugtes Root-Dateisystem und verschwinden vollständig, sobald sie geschlossen werden. Ein typischer Anwendungsfall ist der Umgang mit Anhängen: In Qubes OS kann ein Mail-Client wie Thunderbird einen PDF-Anhang mit einem Knopf direkt in einer Disposable-VM öffnen. Wenn das Dokument Malware enthält, wird diese zusammen mit der gesamten Disposable-VM beim Herunterfahren dieser Disposable-VM gelöscht, ohne dass der Rest des Systems betroffen ist.

Hardware-Anforderungen und Alltagstauglichkeit

Die beschriebenen Mechanismen sind nicht „kostenlos“. Qubes OS startet viele virtuelle Maschinen parallel, was entsprechende Hardware voraussetzt. Für ernsthafte Hochsicherheits-Setups, in denen jede Anwendung ihren eigenen Qube erhält und mehrere Qubes gleichzeitig geöffnet sind, ist viel Arbeitsspeicher nötig. In der Praxis sind 64 GB RAM eine sinnvolle Größenordnung, dazu eine schnelle NVMe-SSD und ein leistungsfähiger Mobil- oder Desktop-Prozessor.

Nicht jede Hardware funktioniert dabei gleich gut mit Xen und der speziellen Qubes-Architektur. Themen wie Grafiktreiber, Suspend/Resume-Verhalten oder bestimmte WLAN-Chipsätze können problematisch sein. Die Qubes-Hardware-Kompatibilitätsliste ist daher ein wichtiges Werkzeug bei der Auswahl geeigneter Geräte; typischerweise kommen eher solide Business-Notebooks und Workstations in Frage, deren Komponenten gut dokumentiert sind und die in der Praxis erprobt wurden.

Ist Qubes OS als Alltagslösung für normale Anwender geeignet?

Qubes OS lässt sich grundsätzlich auch als Alltags-Desktop nutzen. Es ist aber kein System, das man nebenbei ausprobiert und das sich in wenigen Minuten erschließt. Es erfordert eine gewisse Einarbeitungszeit: Man muss sich daran gewöhnen, Anwendungen getrennt in unterschiedlichen Qubes zu betreiben, bewusste Entscheidungen über Datenflüsse zu treffen und das eigene Arbeiten in Sicherheitszonen zu strukturieren.

Für Anwenderinnen und Anwender, die vor allem einige Office-Anwendungen, einen Browser und gelegentlich Streaming nutzen, ist ein gut gepflegtes klassisches System oft die pragmatischere Lösung. Sobald jedoch viele sensible Zugänge, Admin-Zugriffe oder geschäftskritische Daten auf einem Gerät zusammenkommen, verschiebt sich der Trade-off.

Für wen lohnt sich Qubes OS?

Qubes OS lohnt sich vor allem für Menschen und Organisationen mit hohen Sicherheitsanforderungen. Dazu gehören zum Beispiel Administratoren, DevOps-Engineers und SREs mit Zugriff auf produktive Linux-Server, Sicherheitsforscher und Incident-Responder, Journalistinnen und Aktivisten mit sensiblen Quellen sowie alle, für die ein kompromittierter Arbeitsplatzrechner existenzielle Konsequenzen haben kann.

Für diese Zielgruppen bietet Qubes OS ein Sicherheitsmodell, das weit über das hinausgeht, was klassische Desktops liefern, ohne dass dafür auf produktives Arbeiten verzichtet werden muss. Die Konzepte von Xen-basierten Qubes, dom0, TemplateVMs, AppVMs, Disposable-VMs und die mehrstufige Netzwerk-Isolation bilden zusammen einen Hochsicherheits-Desktop, der sich sehr fein auf die jeweiligen Bedrohungsmodelle zuschneiden lässt.

Qubes OS ist damit kein Allheilmittel, aber ein sehr konsequenter Ansatz, die unvermeidbaren Fehler der Softwarewelt zu akzeptieren und ihre Auswirkungen so weit wie möglich zu begrenzen.