© Liu Feng, 123RF.com

Für sichere Betriebssysteme gibt es viele Ansätze, doch häufig krankt es an Details. Der Neuling Qubes OS setzt auf einen Microkernel und durchgängige Virtualisierung. Der erste Eindruck ist positiv.

Jetzt also Qubes OS [1]: Braucht die Welt ein weiteres als besonders sicher deklariertes Betriebssystem? Es gibt doch bereits Open BSD: zwei Remote-Sicherheitslücken in den letzten 16 Jahren – davon träumen andere. Open BSD macht zudem konzeptionell alles richtig: Es gewährleistet Sicherheit durch Qualitätsmanagement, wozu Code Reviews, Coding-Standards sowie automatisierte Tests gehören – nach Ansicht der meisten Experten ist das der beste Weg.

Denn den größten Teil aller relevanten Sicherheitsprobleme verdanken wir typischen und altbekannten Programmierfehlern: Einbrüche geschehen durch Buffer Overflows, Format-String-Schwachstellen, Off-by-one-Fehler und manchmal auch durch fehlerhaft initialisierte Zufallszahlengeneratoren [2].

Ergänzend zu diesen Maßnahmen baut Open BSD eine Vielzahl zusätzlicher Hindernisse ein [3], die Angriffe erheblich erschweren, sollten doch sicherheitsrelevante Fehler ans Licht kommen. Diesen Teil der Strategie kopiert mittlerweile sogar Microsoft für Windows. Grundsätzlich gilt dabei: Prävention ist besser als Reaktion. Alle nachgerüsteten Sicherheitsfeatures, etwa Address Space Layout Randomization, sind reaktiv: Sie lösen das Problem der zugrunde liegenden Programmierfehler nicht.

Auftritt Qubes

Der polnischen Security-Forscherin Joanna Rutkowska gehen die sehr erfolgreichen Ansätze von Open BSD noch nicht weit genug. Auch künstliche Erweiterungen wie SE Linux hält sie für ineffektiv. Bekannt wurde sie unter anderem mit ihrer Arbeit an Blue Pill [4], einem Rootkit, das vom Gastsystem aus den Hypervisor angreift.

Vor diesem Hintergrund arbeitet sie nun an Qubes OS, das unter der GPLv2 steht und dessen fertige Version 2.0 – Release 2 oder R2 genannt – vermutlich Anfang oder Mitte 2014 erscheint. Aktuell ist die Beta 2 vom Februar 2013 zu haben, eine dritte Beta ist noch in Arbeit, sollte aber schon vor drei Monaten erschienen sein.

GUI-Level-Separation

Einer von Rutkowskas Hauptkritikpunkten an den vorhandenen Sicherheitslösungen zielt auf die Unsicherheit von X11: Dort seien Anwendungen, bedingt durch das biblische Alter des X-Window-Systems, nur unzureichend gegeneinander abgeschottet.

Als einfache Demonstration schlägt sie einen kleinen Test mit dem Standardtool »xinput« und zwei Terminalfenstern vor. Nach der parameterlosen Eingabe von »xinput« erscheint eine Liste der verfügbaren Eingabegeräte. Das haben die Tester in Abbildung 1 nachvollzogen und

xinput test 8

eingegeben, wobei die »8« für das benutzte Keyboard steht. Fortan erscheinen alle Tastatureingaben als Scancodes (Abbildung 2), auch wenn der Tippende das zweite Terminal verwendet – oder gar mit Rootrechten arbeitet!

Abbildung 1: Das Kommandozeilentool »xinput« zeigt Eingabegeräte an.

Abbildung 2: Der Befehl »xinput test 8« zeichnet die Tastatur-Scancodes auf – in diesem Fall »su -« gefolgt vom Rootpasswort.

Im Beispiel hatten die Tester zunächst »su -« aufgerufen, was die ersten acht Scancodes erzeugte. Dann folgte [Enter] und ihr Rootpasswort für die Kali-VM – wer nachprüft, wird merken, dass es recht unsicher ist. Immerhin funktioniert dieser Lauschangriff nicht für X11-Forwarding über SSH – zumindest nicht, um zu lauschen, was der auf dem entfernten Rechner Arbeitende für Befehle eingibt.

Umgekehrt lassen sich lokale Eingaben für das entfernte System natürlich mitschneiden. Technisch sauberer wäre es, wenn zumindest der Übergriff auf den anderen Nutzer nach der Eingabe von »su -« unmöglich wäre. Doch auch das könnte nur ein Notbehelf sein, denn grundsätzlich sollte keine Anwendung Daten einer anderen erhalten.

App-Separation

Diese Idee spinnt Qubes OS weiter: Statt alle Anwendungen nebeneinander laufen zu lassen, legt es für Gruppen von Anwendungen jeweils geeignete Sicherheitsstufen fest. Diese Gruppen landen dann in einer eigenen Xen-VM, was die Apps stärker voneinander kapselt als unter normalen Betriebssystemen. Die Kapselung geht auch weiter als in einer Chroot-Umgebung, in der sich die Systeme die Hardware-Ressourcen, etwa die Netzwerkkarten, teilen.

Wer nun argumentiert, eine solche Sicherheitsmaßnahme durch Aufteilung brauche kein neues Betriebssystem, hierfür würden Parallels, Virtualbox oder VMware völlig genügen, übersieht, dass diese Systeme nur so sicher sind, wie ihr Wirtsbetriebssystem.

Qubes OS setzt auf einen minimalen Wirt, der nur das GUI bereitstellt, wahlweise KDE oder Xfce. Für alles andere, das schließt Hardware wie das Netzwerk oder die Festplatten ein, gibt es eigene VMs (Abbildung 3). Weil dem Wirtssystem ein Netzwerkzugang fehlt, brauchen nur wenige Komponenten Updates, die der Admin über die Kommandozeile einspielt [5].

Abbildung 3: Die Architektur von Qubes OS: Anwendungen landen gruppiert nach ihren Sicherheitsanforderungen in den App-VMs, Hardware abstrahiert Qubes durch eigene VMs.

Netzwerkspielereien

Das Auslagern des Netzanschlusses hat noch einen weiteren Vorteil: Wer per VPN ins Büro tunneln muss, erstellt sich eine Netz-VM, welche die VPN-Verbindung aufbaut, und kann den durch sie bereitgestellten Netzwerkadapter dann mit verschiedenen VMs nutzen. So teilen sich mehrere Sicherheitsumgebungen einen VPN-Tunnel. Der ist dabei völlig transparent für die jeweilige VM, die auch nichts vom eigenen Netz sieht. Das reduziert nebenbei Sicherheitsrisiken, die durch den VPN-Einsatz entstehen könnten.

In ihrem Blog schlägt Rutkowska vor, in einer Netzwerk-Adapter-VM einen Tor-Proxy zu installieren [6]. Hier merkt die App-VM nicht, dass die Netzwerkkarte mehr leistet als üblich – und kann insbesondere den Tor-Proxy nicht umgehen. Die Folge: Der gesamte Netzwerkverkehr wird anonymisiert. Das verhindert die üblichen Angriffe auf die Anonymisierung, etwa durch Flash-Plugins.

Klein ist fein

Neben der guten Hardware-Abstraktion und -Kapselung kommt mit dem eingesetzten Microkernel aus Sicherheitssicht ein weiterer Pluspunkt hinzu: Als sicher eingestufte Programme sollten weniger als 0,5 Fehler pro 1000 Codezeilen haben, das Mittel für Alltagsprogramme liegt bei drei bis fünf Fehlern [7]. Nicht jeder Bug ist sicherheitsrelevant, viele sind einfach nur lästig. Dennoch basieren die meisten derzeit ausgenutzten Sicherheitslücken auf typischen Programmierfehlern.

Mit der Gesamtfehlerzahl reduziert sich auch die der sicherheitsrelevanten Fehler. Und genau das ist einer der wertvollen Nebeneffekte, die ein Microkernel mit sich bringt: Er kommt mit weniger Codezeilen aus. Gerade Sicherheitslücken im Kernel sind fatal und lassen sich besonders effektiv ausnutzen. Daher muss deren Vermeidung für ein sicheres System höchste Priorität haben.

Plattformunabhängig

Mit Hilfe von Templates für die App-VMs ist Qubes OS recht einfach zu konfigurieren, eine neue VM ist schnell aufgesetzt. Das Standard-Template in Qubes R2 Beta 2 basiert auf Fedora 18 (64 Bit), zu Beginn stehen dem Anwender drei farbkodierte App-VMs – Work, Personal und Random – zur Auswahl. Beim Einstieg helfen zudem die zahlreichen Hinweise auf der Webseite.

Durch den zugrunde liegenden Xen-Hypervisor und die eingesetzte Virtualisierungstechnik ist ein Qubes-OS-Anwender nicht auf ein Betriebssystem beschränkt. In den unterschiedlichen App-VMs dürfen verschiedene Systeme laufen. Das Wiki zum Austausch mit den Kollegen im Intranet kann zum Beispiel aus Sicherheitserwägungen auf Open BSD basieren. Die per E-Mail zugeschickten MS-Office-Dateien brauchen keinen Viewer mehr: Sie lassen sich in einer Windows-App-VM nativ lesen. Das schafft ein hohes Maß an Flexibilität und Sicherheit.

Hoher Testaufwand

Apropos hoch: Wer Qubes OS R2 schnell mal ausprobieren möchte, wird vor eine ordentliche Hürde gesetzt: Einerseits ist die Hardware-Kompatibilitätsliste [8] sehr kurz. Auf dem anfangs genutzten Testsystem unter OS X 10.7.5 war keine Virtualisierungsumgebung (Parallels, Virtualbox, VMware Fusion) zur Kooperation mit Qubes zu bewegen.

Das unterstreicht auch die Qubes-Webseite mit dem charmanten Hinweis, man möge doch bitte von weiteren Anfragen an das Entwicklerteam absehen, wie sich Qubes in einer virtuellen Umgebung installieren ließe – das funktioniere schlicht nicht. Dem widersprechen zwar einzelne Berichte auf Webseiten [9], die angeblich Qubes OS als Nested-Virtualisierung zum Laufen gebracht haben, doch leider fehlen überall klare Informationen zu den Bedingungen.

So musste letztlich ein alter Laptop für den Test herhalten, Qubes wurde heruntergeladen [10] und altmodisch auf eine DVD gebrannt. Der Kompatibilitätsliste können die Tester nach einer fast drei Stunden dauernden Installation immerhin ein neues Gerät hinzufügen: ein Macbook Pro aus dem Jahre 2007.

Fazit

Obwohl das Konzept von Qubes OS nicht revolutionär ist – denn App-Separationsverfahren gibt es schon länger –, machen die alltagstaugliche Nutzbarkeit des Systems und die hohe Flexibilität zusammen mit den durchdachten Konzepten zur Geräte-Abstraktion Qubes OS recht einzigartig.

Dennoch ist das System noch nicht für jedermann geeignet, denn die eingeschränkte Hardwarekompatibilität ist zurzeit ein echter Hemmschuh. Außerdem gibt es – wie von einer Betaversion nicht anders zu erwarten – noch einige Bugs zu beheben [11]. Wer sich aber von diesen Punkten nicht abschrecken lässt, erhält ein gut durchdachtes und vor allem sicheres System.