Qubes' Architektur - Verschiedene Arten von VMs

Administrative Domäne

Für die Verwaltung der virtuellen Maschienen ist die administrative Domäne (dom0) zuständig. Da sie besonders sicherheitsrelevant ist, verfügt sie über keine Netzwerkverbindung und bietet auch den anderen Domänen möglichst wenig Schnittstellen an. Die administrative Domäne ist verantwortlich für die Benutzeroberfläche, das Management der virtuellen Maschinen, für die Verwaltung und Backups der virtuellen Festplatten, die den anderen Maschinen zugeordnet sind, und hat außerdem direkten Zugriff auf die Hardware.

Bei den meisten Betriebssystemen wird die Administration von den anderen Benutzern durch unterschiedliche Accounts getrennt. Durch Privilege Escalation kann ein schadhaftes Programm, das mit normalen Benutzerrechten gestartet wurde aber trotzdem Administrator-Rechte erlangen und dann das gesamte System übernehmen. Deswegen setzt Qubes auf eine striktere Trennung der Adminstration von den Benutzeranwendungen. Hier ist das Pendant zum Administrator-Account die administrative Domäne dom0, wohingegen die normalen Benutzer-Accounts den unpriviligierten VMs entsprechen. Aus diesem Grund ist Qubes auch ein Single-User Betriebssystem.

Architekturabhängige Domänen

Architekturabhängige Domänen lassen sich in zwei Gruppen einteilen. Die erste Gruppe umfasst die installierten Templates, die sowohl die Grundlage für AppVMs, als auch für die dienstleistenden Domänen bilden. Die zweite Gruppe besteht aus VMs, die zwar Systembezug besitzen, aber aus Sicherheitsgründen von der administrativen Domäne isoliert werden. Meist erfüllen diese Domänen bestimmte Aufgaben oder ihnen ist eine bestimmte Hardware zugeordnet.

TemplateVMs

Um den Zusammenhang zwischen AppVMs und TemplateVMs zu verstehen, sind Kenntnisse der Linux-Verzeichnisstruktur nötig. In einer Linux-Distribution gibt es zum einen die Standard-Benutzer, die vollen Zugriff auf ihr Home-Verzeichnis haben und beschränken Zugriff (z. B. nur lesend und ausführend) auf das restliche Dateisystem. So können sie installierte Programme ausführen und Konfigurationen lesen, aber nichts verändern. Nur der Administrator root hat schreibenden Zugriff auf das gesamte Dateisystem. Soll jetzt z. B. eine neues Programm installierte werden oder die Konfiguration des Betriebssystems verändert werden, dann sind Administrator-Rechte nötig, da Standard-Benutzer aus Sicherheitsgründen nicht die erforderlichen Rechte besitzen, um Dateien in den betroffenen Verzeichnissen zu erstellen oder zu verändern. Da immer wieder Sicherheitslücken und Bugs gefunden werden, mit denen ein - möglicherweise kompromittierter - Standard-Benutzer die sicherheitskritischen Administrator-Rechte erlangen kann, wird das Konzept der verschiedenen Accounts bei Qubes durch verschiedene virtuelle Maschinen umgesetzt.

Die TemplateVM stellt allen ihr zugeordneten AppVMs das eigene root-Dateisystem lesend zur Verfügung. So wird sichergestellt, dass die AppVMs nur die Software verwenden können, die in der jeweiligen TemplateVM installiert ist und diese auch nicht verändern können. Wird eine AppVM durch eine fehlerhafte Benutzeranwendung kompromittiert, so können keine dauerhaften Veränderungen an der Software oder der Konfiguration vorgenommen werden, da beim nächsten Start der AppVM wieder das root-Dateisystem der jeweiligen TemplateVM geladen wird. Da die AppVM nur lesenden Zugriff auf das root-Dateisystem der TemplateVM besitzt, kann sie keine dauerhaften Veränderungen an der Software und Konfiguration vornehmen. Lediglich die Benutzerdaten der AppVM können dauerhaft verändert werden, vergleichbar mit einem Standard-Benutzer der vollen Zugriff auf seine Daten im Home-Verzeichnis besitzt.

Standardmäßig sind bei einer Qubes-Installation Templates für die Betriebssysteme Fedora, Debian und Whonix verfügbar.

ServiceVMs

Die dienstleistenden Domänen werden standardmäßig bei der Installation erstellt und stellen dem Gesamtsystem verschiedene Dieste zur Verfügung. Aus Sicherheitgründen sind sie von der administrativen Domäne getrennt, erfüllen aber trotzdem systemrelevante Aufgaben und sollten deswegen nicht für Benutzeranwendungen verwendet werden. Sie sind wie AppVMs von TemplateVMs abgeleitet. Meist ist ihnen eine bestimmte Hardware zugeordnet, die zur Erfüllung ihrer Aufgaben nötig ist. Standardmäßig gibt es folgende ServiceVMs:

sys-net
eine AppVM, deren einzige Aufgabe darin besteht, für das Gesamtsystem die Netzwerkverbindung bereitzustellen. Um diese Aufgabe zu bewältigen ist ihr als Hardware die Netzkarte zugeordnet.
sys-firewall
eine AppVM, die als ProxyVM zwischen sys-net und eine beliebige AppVM mit Netzwerkzugang geschalten wird. Das hat den Vorteile, dass sich AppVMs nicht direkt mit der potentiell gefährdeten NetVM sys-net verbinden, sondern ihre Netzwerkverbindung von sys-firewall bereitgestellt wird. Außerdem enthält sys-firewall das Regelwerk für die kernelbasierende Firewall und wendet sie auf den, über sie geleiteten, Datenverkehr an. Die Trennung zwischen sys-net und sys-firewall hat außerdem noch den Vorteil, dass eine Kompromittierung von sys-net - z. B. über einen fehlerhaften Treiber der Netzkarte - keinen Einfluss auf das Regelwerk der Firewall hat, da es sich um zwei unabhängige, voneinerander isolierte VMs handelt.
sys-whonix
eine AppVM, die als ProxyVM zwischen sys-firewall und eine beliebige Whonix-AppVM mit Netzwerkzugang geschalten wird. Ihre Aufgabe besteht darin, als Proxy nur Netzverkehr zuzulassen, der an das Tor-Netzwerk adressiert ist und anderen Netzverkehr, der die Anonymität gefährden könnte, zu verwerfen.
sys-usb
eine AppVM, die die USB-Controller von der administrativen Domäne isoliert. Nachdem ein USB-Gerät angeschlossen wird steht es in der AppVM sys-usb zur Verfügung. Von dort kann es einer beliebigen AppVM zugeordenet werden. So wird verhindert, dass USB-Geräte mit Schadsoftware Zugriff auf die administrative Domäne bekommen. Stattdessen kann das USB-Gerät, von sys-usb ausgehend, der gewünschen AppVM zugeordnet werden.

Bei Bedarf können weitere, benutzerspezifische, serviceorientierte VMs konfiguiert werden. Zum Beispiel eine eigene NetVM für öffentliche WLAN-Netze nach dem Vorbild von sys-net oder eine isolierte ProxyVM für sicheren VPN-Zugang zu einem Unternehmensnetzwerk.

Domänen für Benutzeranwendungen

Die virtuellen Maschinen, in denen Benutzeranwendungen ausgeführt werden, basieren auf einer bestimmten TemplateVM und werden AppVMs genannt. Von einer TemplateVM können mehrere AppVMs abgeleitet werden. Werden Benutzeranwendungen von verschiedenen Betriebssystemen benötigt, so müssen zuerst die entsprechenden Templates installiert und konfiguriert werden. Dann können darauf basierend die jeweiligen AppVMs erstellt werden. Es gibt außerdem verschiedene Unterkategorien von AppVMs, die im Folgenden näher erläutert werden.

AppVMs

AppVMs bekommen von einer TemplateVM das root-Dateisystem im read-only-Modus zur Verfügung gestellt. Sie bestimmt also das Betriebssystem, die installierten Programme und die Konfiguration. Werden mehrere AppVMs von einer TemplateVM abgeleitet, so besitzen alle die gleichen Betreibssystem-Konfigurationen und installierten Programme.

Mit der Standard-Installation werden, neben den ServiceVMs, die AppVMs untrusted, personal, work und vault eingerichtet, die auf dem Fedora-Template basieren. Außerdem wird eine AppVM anon-whonix erstellt, die auf dem Whonix-Template basiert und einen anonymen Internetzugang enthält.

Wird beispielsweise im Fedora-Template ein neues Programm installiert, steht es den vier AppVMs untrusted, personal, work und vault zur Verfügung, da diese alle auf dem Fedora-Template basieren. Die AppVM anon-whonix hingegen kann das Programm nicht verwenden, da sie von einem anderen Template (whonix-ws) abgeleitet ist.

Bei Bedarf können über den Qube Manager noch weitere AppVMs erstellt werden. Beispielsweise solche, die auf dem Debian-Template basieren.

StandaloneVMs

Der Unterschied zwischen StandaloneVMs und anderen AppVMs besteht darin, dass StandaloneVMs zwar bei ihrer Erstellung von einer TemplateVM abgeleitet werden, danach aber ihr eigenes root-Dateisystem besitzen und autonom Programme installieren und Konfigurationen ändern können. Bei anderen AppVMs hingegen wird bei jedem Neustart das root-Dateisystem der jeweiligen TemplateVM eingebunden. Änderungen müssen deshalb in der TemplateVM vergenommen werden und betreffen dann aber alle darauf basierenden AppVMs. StandaloneVMs sind also nach ihrer Erstellung von der TemplateVM entkoppelt. Deswegen eigenen sie sich besonders, wenn abweichende Konfigurationen oder Programme benötigt werden, die den anderen AppVMs nicht zur Verfügung stehen sollen.

Wenn z. B. ein lokaler Webserver installiert werden soll, dann könnte man diesen in der TemplateVM installierten, was dazu führen würde, dass auf allen AppVMs jetzt ein Webserver läuft. Das ist in den meisten Fällen nicht gewünscht. Stattdessen empfiehlt es sich, eine StandaloneVM zu erstellen und in dieser dann den Webserver zu installieren, zu konfigurieren und zu betreiben.

Der Nachteil besteht darin, dass StandaloneVMs deswegen viel mehr Speicherplatz benötigen, da jede ihr eigenes root-Dateisystem besitzt und es nicht mit anderen AppVMs teilt.

DVM Templates und DisposableVMs

DisposableVMs sind Wegwerf-VMs, die nur zum Öffnen einer nicht vertrauenswürdigen Datei oder eines nicht vertrauenswürdigen Links erstellt und danach wieder gelöscht werden. Mittels Rechtsklick auf eine Datei kann die qubesinterne Option "Open in DisposableVM" ausgewählt werden. Daraufhin wird automatische eine VM erstellt, die nur zur Ausführung von einer einzelnen Anwendung gedacht ist und die nach dem Schließen der Anwendung automatisch wieder gelöscht wird. Außerdem werden DisposableVMs benutzt um die qubesinternen Funktionen "Convert To Trusted Img" und "Convert To Trusted Pdf" zu nutzen. Dabei wird die .pdf-Datei oder das Image im Hintergrund in einer DisposableVM geöffnet, dann in das vertrauenswürdige Format konvertiert und die DisposableVM danach wieder gelöscht.

Bei der Qubes-Version R3 gibt es nur ein einziges DVM Template, auf der alle DisposableVMs, die von allen AppVMs aus erstellt werden, basieren.

Bei Qubes R4 kann grundsätzlich jede AppVM zu einem DVM Template umfunktioniert werden. Über den Qube Manager kann dann jeder AppVM ein DVM Template aus der Liste zugeordnet werden, das dann die Grundlage für die DisposableVMs bildet, wenn sie von dieser AppVM aus erstellt werden.

Per Default sind die DVM Templates fedora-26-dvm und whonix-ws-dvm vorinstalliert. Dabei ist fedora-26-dvm den AppVMs untrusted, personal, work und vault als DVM Template zugeordnet. Wenn von diesen AppVMs aus eine DisposableVM erstellt wird, dann basiert sie auf fedora-26-dvm. Bei der AppVM anon-whonix hingegen basieren die DisposableVMs auf dem DVM Template whonix-ws-dvm.


Erfahren Sie mehr über Qubes' VM Features