Isolation: Der Schlüssel zur nahezu absoluten Sicherheit?

Schon manch ein Hersteller hat sich mit dem Bekenntnis zur „100%igen Sicherheit“ verschluckt, obwohl wir doch alle wissen, dass dieser Zustand nie erreicht werden kann. Das alleine treibt aber Menschen an. Ihr Eifer für die Sache und ihre Hingabe resultieren häufig in Lösungen, die uns zum Ziel näher bringen sollen. Genau so gilt dies auch für die Macher des Betriebssystems Qubes OS.

Grundprinzipien von Qubes OS

Die beiden großen Stützpfeiler der IT Sicherheitsstrategie von Qubes OS sind folgende:

  • Linux
  • Virtualisierung

Es fällt mir schwer Linux als IT Sicherheitstrategie hier vorzuführen, da erst kürzlich beim Pwn2Own Wettbewerb gezeigt worden ist wie angreifbar auch Linux ist. Selbstverständlich ist jedes IT System angreifbar, aber manche sind öfter das Ziel als andere. Und seien wir ehrlich, führt man dies auf die Spitze, so könnte keine einzige Strategie hier aufgezählt werden, denn über geschicktes Social Engineering wurde noch jede IT Sicherheitshürde gemeistert.
Aus diesem Grund bleibe ich erst einmal bei der Behauptung, dass Linux tatsächlich sicherer ist wie beispielsweise Windows. Die Gefahr angegriffen zu werden ist aber nach wie vor vorhanden.

Auch Virtualisierung als solches ist noch lange kein Garant für Sicherheit. Natürlich lässt sich damit der Schaden begrenzen. Verteilt man eine Infrastruktur, bestehend aus vielen Diensten auf viele Server, ist eventuell ein System kompromitiert, die anderen aber bleiben vorerst sauber.

Unterschiede bei der Virtualisierung

Grundsätzlich gibt es bei der Virtualisierung zwei unterschiedliche Typen:

  • Typ-1-Hypervisor
  • Typ-2-Hypervisor

Fast jeder Systemadministrator hat sicherlich schon mit beiden zu tun gehabt. Während die Typ-1-Hypervisoren in Form von VMware ESX, Hyper-V oder XenServer daher kommen, bilden die Typ-2-Hypervisoren die Desktop Sparte wie etwa Oracle Virtual Box oder VMware Workstation. Wo liegt der Unterschied?

Typ-1-Hypervisoren liefern eine höhere Verfügbarkeit, Performanz und vor allem Sicherheit. Typ-2-Hypervisoren hingegen benötigen ein Hostbetriebssystem, worauf sie laufen können. Damit sind dort laufende Gastbetriebssysteme auch nur so sicher, wie der Host selbst. Dies trickst der Typ-1-Hypervisor dadurch aus, dass er direkt auf der Hardware läuft und kein eventuell geschwächtes Hostsystem benötigt. Kleine Logikfrage am Rande: Welche Nachteile hat der Typ-1-Hypervisor dadurch?
Antwort: Ohne Hostbetriebssystem, muss der Hypervisor alle nötigen Treiber mitbringen, um die darunterliegende Hardware zu unterstützten. Dies klappt hin und wieder nicht, wenn die Hardware ein Desktoprechner ist, der als Typ-1-Hypervisor missbraucht wird. Habe ich schon gemacht, und prompt wurde die Netzwerkkarte nicht erkannt.

Wie funktioniert nun die Isolation?

Die Basis von Qubes OS ist der Typ-1-Hypervisor Xen von Citrix. Qubes OS virtualisiert allerdings keine neuen Betriebssysteme, sondern direkt einzelne Anwendungen und packt diese in sogenannte qubes. Ähnlich wie bereits weiter oben beschrieben wird dadurch die Angriffsfläche stark verkleinert, denn wenn eine Anwendung durch einen Angreifer übernommen worden ist, so hat er nicht einmal einen ganzen Server, geschweige denn ein gesamtes Betriebssystem erobert. Nur eine Anwendung ist ihm zum Opfer gefallen. So schön, wie ich diese Idee auch halte, hat sie einen Knackpunkt, denn auch das kann reichen. Handelt es sich beim Programm etwa um einen schlecht konfigurierten MTA (Mail Transfer Agent), so könnte der Angreifer den Dienst als Spamschleuder verwenden. Das würde ja schon für diesen Zweck ausreichen.

Nicht nur Anwendungen können damit isoliert werden. Qubes verpackt sogar die Systemfunktionen in eine virtuelle Box, um ewta Zugriffe auf die Hardware zu ermöglichen. Damit lässt sich kein Code direkt im Hypervisor ausführen. Programme, die also auf die Hardware zugreifen wollen, werden zu einer etwas höher privilegierten VM geschickt, die in diesem Zusammenhang als „Control Domain“ bekannt ist. Abgekürzt wird diese mit dom0. Eine Code Injection in den Hypervisor, über den Zugriff auf die Hardware, wird damit stark erschwert. Gleichzeitig muss aber jede andere VM auf dom0 zugreifen dürfen.

Installation

Das ISO Image von QubesOS lässt sich einfach herunterladen und auf einen bootfähigen USB Stick installieren:

Erforderlich für eine optimale Ausführung sind folgende Systeme:

  • Intel VT-x
  • Intel VT-d
  • AMD-V
  • AMD-Vi/AMD IOMMU
  • TPM-Chip

In der Regel hat man entweder die AMD oder die Intel Systeme auf der Hardware. Ohne diese fehlen eben Möglichkeiten der Isolation verschiedener Ausführungstypen. Der TPM Chip beispielsweise wird für das Isolieren der USB Geräte benötigt.

Fazit

Der Ansatz ist natürlich nicht neu, den QubesOS hier verfolgt. Die Umsetzung hingegen halte ich für interessant. Vor allem aber ist mir die Frage in den Sinn gekommen, die mir Kunden seit einiger Zeit stellen: „Was kann ich gegen Bad USB oder Rubber Duckys unternehmen?“. Eventuell lässt sich so ein Angriff über QubesOS unterbinden, wenn ein TPM Chip im Einsatz ist. Über diesen kann das Betriebssystem die USB Geräte trennen, damit eventuell auch etwas gegen Bad USB unternehmen? Was denkt ihr darüber?

Schlussendlich ist QubesOS kein Allheilmittel, aber definitv eine Iterationsstufe weiter im Kampf gegen die Gefahren aus dem Web. Probiert es aus und berichtet mir. Dann machen wir darüber gemeinsam einen Blogartikel. Da mein Notebook, welches QubesOS samit Intel VT-x und VT-d ausführen könnte, in Reparatur ist, kann ich leider keine Livetests vorweisen. Auf diesem Notebook hier lässt sich QubesOS leider nicht booten.

 Beitragsbild: Mail Boxes (verändert) von Rae Allen unter CC-BY-2.0

Artikel teilen:

Kommentar verfassen