Die Verwendung von QubesOS zur Arbeit mit Windows 7

Auf Habr gibt es nicht viele Artikel über das Betriebssystem Qubes, und die wenigen, die ich gesehen habe, beschreiben kaum die Anwendungserfahrungen. Ich hoffe, dies im Folgenden anhand der Nutzung von Qubes als Schutzmaßnahme für Windows-Umgebungen zu verbessern und dabei die Anzahl der russischsprachigen Nutzer dieses Systems zu bewerten.

Warum Qubes?

Die Einstellung des Supports für Windows 7 und die wachsende Besorgnis der Nutzer haben die Notwendigkeit zur Organisation der Nutzung dieses OS ausgelöst, wobei folgende Anforderungen berücksichtigt werden mussten:

• vollständig aktivierte Windows 7 bereitzustellen, die es dem Nutzer ermöglicht, Updates und verschiedene Anwendungen (einschließlich über das Internet) zu installieren;
• vollständigen oder selektiven Ausschluss von Netzwerkverbindungen nach bestimmten Bedingungen (Offline-Modus und Traffic-Filtration);
• die Möglichkeit zu bieten, Wechselmedien und Geräte selektiv anzuschließen.

Dieses Set von Einschränkungen setzt einen klar vorbereiteten Benutzer voraus, da eine eigenständige Verwaltung erlaubt ist und die Einschränkungen nicht mit der Blockierung potenzieller Aktionen verbunden sind, sondern darauf abzielen, mögliche Fehler oder destruktive Softwareeinwirkungen zu vermeiden. Das heißt, es gibt keinen internen Angreifer in diesem Modell.

Auf der Suche nach einer Lösung haben wir schnell die Idee verworfen, Einschränkungen mit integrierten oder zusätzlichen Mitteln von Windows umzusetzen, da es ziemlich schwierig ist, einen Benutzer mit Administratorrechten effektiv einzuschränken, während ihm gleichzeitig die Möglichkeit gegeben wird, Anwendungen zu installieren.

Die nächste Lösung bestand in der Isolation durch Virtualisierung. Bekannteste Tools für Desktop-Virtualisierung (wie z.B. VirtualBox) sind jedoch schlecht geeignet für Sicherheitslösungen, und die genannten Einschränkungen müssen vom Benutzer ständig durch Umschalten oder Anpassen der Eigenschaften der Gästemaschine (VM) vorgenommen werden, was die Fehleranfälligkeit erhöht.

Gleichzeitig haben wir Erfahrung mit der Nutzung von Qubes als Desktop-System gesammelt, jedoch gab es Bedenken hinsichtlich der Stabilität bei der Arbeit mit dem Gast-Windows. Daher wurde beschlossen, die aktuelle Version von Qubes zu testen, da die gegebenen Einschränkungen sehr gut in die Paradigmen dieses Systems passen, insbesondere die Implementierung von Vorlagen für virtuelle Maschinen und die visuelle Integration. Im Folgenden werde ich versuchen, die Ideen und Werkzeuge von Qubes anhand der Lösung dieser Aufgabenstellung kurz darzustellen.

Arten der Virtualisierung von Xen

Im Kern von Qubes befindet sich der Hypervisor Xen, der die Funktionen für das Ressourcenmanagement von CPU, Speicher und virtuellen Maschinen minimiert. Alle weiteren Arbeiten mit Geräten konzentrieren sich auf dom0, das auf einem Linux-Kernel basiert (für dom0 wird in Qubes eine Fedora-Distribution verwendet).

Xen unterstützt mehrere Arten der Virtualisierung (ich werde Beispiele für die Intel-Architektur anführen, obwohl Xen auch andere unterstützt):

• Paravirtualisierung (PV) – ein Virtualisierungsmodus ohne Hardwareunterstützung, ähnlich der Container-Virtualisierung, kann für Systeme mit einem angepassten Kernel verwendet werden (in diesem Modus funktioniert dom0).
• Vollständige Virtualisierung (HVM) — in diesem Modus wird die Hardwareunterstützung für die CPU-Ressourcen verwendet, während die gesamte andere Hardware durch QEMU emuliert wird. Dies ist die vielseitigste Methode, um verschiedene Betriebssysteme zu starten;
• Paravirtualisierung der Hardware (PVH — ParaVirtualized Hardware) — ein Virtualisierungsmodus mit Hardwareunterstützung, bei dem der Kernel des Gastbetriebssystems angepasste Treiber verwendet, um mit der Hardware zu interagieren (z. B. Shared Memory), wodurch die Notwendigkeit der QEMU-Emulation entfällt und die I/O-Leistung gesteigert wird. Der Linux-Kernel ab Version 4.11 kann in diesem Modus betrieben werden.

Seit der Version Qubes 4.0 wird aus Sicherheitsgründen auf den Paravirtualisierungsmodus verzichtet (unter anderem aufgrund bekannter Schwachstellen in der Intel-Architektur, die teilweise durch vollständige Virtualisierung behoben werden), standardmäßig wird der PVH-Modus verwendet.

Bei der Verwendung der Emulation (HVM-Modus) wird QEMU in einer isolierten VM namens stubdomain gestartet, wodurch Risiken durch potenzielle Implementierungsfehler verringert werden. Das QEMU-Projekt enthält eine Vielzahl von Code, einschließlich Kompatibilitätsfunktionen.
Für unseren Fall sollte dieser Modus für Windows verwendet werden.

Dienst-Virtual-Maschinen

In der Sicherheitsarchitektur von Qubes ist eine der wesentlichen Funktionen des Hypervisors die Möglichkeit, PCI-Geräte an die Gastumgebung weiterzuleiten. Das Herausnehmen von Hardware ermöglicht es, den Host-Teil des Systems vor externen Angriffen zu isolieren. Xen unterstützt dies für PV- und HVM-Modi; im zweiten Fall ist die Unterstützung von IOMMU (Intel VT-d) erforderlich – eine Hardwareverwaltung des Speichers für virtualisierte Geräte.

Auf diese Weise werden mehrere System-Virtual-Maschinen erstellt:

• sys-net, dem Netzwerkgeräte zugewiesen werden und das als Brücke für andere VMs dient, z. B. für Firewalleinstellungen oder als VPN-Client;
• sys-usb, dem USB- und andere Controller für Peripheriegeräte zugewiesen werden;
• sys-firewall, die keine physikalischen Geräte verwendet, sondern als Firewall für angeschlossene VMs fungiert.

Für die Arbeit mit USB-Geräten werden Proxy-Dienste eingesetzt, die unter anderem Folgendes ermöglichen:

• für die Klasse der HID-Geräte (Human Interface Device) die Übertragung von Befehlen an dom0;
• für wechselbare Speichermedien die Umleitung von Gerätetoken an andere VMs (außer dom0);
• direkte Umleitung des USB-Geräts (unter Verwendung von USBIP und Integrationswerkzeugen).

In einer solchen Konfiguration kann ein erfolgreicher Angriff über den Netzwerk-Stack oder angeschlossene Geräte nur die aktive Dienst-VM kompromittieren, nicht das gesamte System. Nach einem Neustart der Dienst-VM wird sie im ursprünglichen Zustand geladen.

Integrationswerkzeuge für VMs

Es gibt mehrere Möglichkeiten, mit dem Desktop der virtuellen Maschine zu interagieren: Anwendungen können im Gastbetriebssystem installiert oder die Videoausgabe durch Virtualisierung emuliert werden. Als Gastanwendungen können verschiedene universelle Remote-Access-Tools (RDP, VNC, Spice usw.) oder speziell für einen bestimmten Hypervisor angepasste Tools verwendet werden (solche Instrumente werden oft als Gastwerkzeuge bezeichnet). Es kann auch eine hybride Lösung eingesetzt werden, bei der der Hypervisor die Ein- und Ausgabe für das Gastbetriebssystem emuliert und extern die Möglichkeit bietet, ein Protokoll zu verwenden, das Ein- und Ausgabe kombiniert, wie es bei Spice der Fall ist. Dabei optimieren Remote-Access-Tools normalerweise die Anzeige, da sie für den Betrieb über das Netzwerk konzipiert sind, was jedoch die Bildqualität beeinträchtigen kann.

Qubes bietet eigene Mittel zur Integration von VMs an. Im Vordergrund steht dabei das grafische System — Fenster aus verschiedenen VMs werden auf einem einheitlichen Desktop mit individuellen farblichen Rahmen angezeigt. Die Integrationsmittel basieren insgesamt auf den Möglichkeiten des Hypervisors — geteiltem Speicher (Xen Grant Table), Benachrichtigungssystemen (Xen Event Channel), gemeinsam genutztem Speicher xenstore und dem Kommunikationsprotokoll vchan. Damit werden die grundlegenden Komponenten qrexec und qubes-rpc sowie Anwendungsdienste wie Audio- oder USB-Weiterleitung, Dateitransfer oder Clipboard-Inhalt, Ausführung von Befehlen und Starten von Anwendungen realisiert. Es besteht die Möglichkeit, Richtlinien festzulegen, die den Zugriff auf verfügbare Dienste in der VM einschränken. Im Bild unten ist ein Beispiel für die Initialisierung der Interaktion zwischen zwei VMs dargestellt.

So erfolgt die Arbeit in der VM ohne Nutzung des Netzwerks, was die vollständige Nutzung von autonomen VMs ermöglicht, um Datenlecks zu vermeiden. Dies wird beispielsweise durch die Trennung kryptografischer Operationen (PGP/SSH) erreicht, bei der private Schlüssel in isolierten VMs verwendet werden und deren Grenzen nicht überschreiten.

Vorlagen, Anwendung und Einmal-VMs

Alle Benutzeraktivitäten in Qubes erfolgen in virtuellen Maschinen. Das Hauptbetriebssystem wird verwendet, um deren Betrieb zu steuern und zu visualisieren. Das Betriebssystem wird zusammen mit einem grundlegenden Satz an auf Vorlagen (TemplateVM) basierenden virtuellen Maschinen installiert. Eine solche Vorlage ist eine Linux-VM, die auf einer Fedora- oder Debian-Distribution basiert und über installierte und konfigurierte Integrationswerkzeuge sowie separate System- und Benutzerdatenpartitionen verfügt. Die Installation und Aktualisierung von Software erfolgt über den integrierten Paketmanager (dnf oder apt) aus den konfigurierten Repositories mit obligatorischer Überprüfung der digitalen Signatur (GnuPG). Der Zweck dieser VMs besteht darin, Vertrauen in die darauf basierenden Anwendungs-VMs zu gewährleisten.

Die Anwendungs-VM (AppVM) verwendet beim Start einen Snapshot des Systembereichs der entsprechenden VM-Vorlage und entfernt diesen Snapshot nach dem Abschluss ohne Änderungen zu speichern. Die benötigten Benutzerdaten werden in einem für jede Anwendungs-VM einzigartigen Benutzerdatenbereich gespeichert, der im Home-Verzeichnis eingebunden wird.

Eine nützliche Sicherheitsmaßnahme kann die Verwendung von Einmal-VMs (disposibleVM) sein. Diese VM wird beim Start auf Basis einer Vorlage erstellt und verfolgt das einzige Ziel — die Ausführung einer Anwendung, die nach deren Beendigung sofort wieder heruntergefahren wird. Einmal-VMs können verwendet werden, um verdächtige Dateien zu öffnen, deren Inhalte möglicherweise spezifische Anwendungsanfälligkeiten ausnutzen. Die Möglichkeit, eine Einmal-VM zu starten, ist in den Dateimanager (Nautilus) und den E-Mail-Client (Thunderbird) integriert.

Windows-VMs können auch zur Erstellung von Vorlagen und temporären VMs verwendet werden, wobei das Benutzerprofil in einen separaten Bereich übertragen wird. In unserem Beispiel wird diese Vorlage vom Benutzer für Verwaltungsaufgaben und die Installation von Anwendungen genutzt. Auf Basis der Vorlage werden mehrere Anwendungs-VMs erstellt – mit eingeschränktem Netzwerkzugang (Standardmöglichkeiten von sys-firewall) und ohne Netzwerkzugang überhaupt (es wird kein virtuelles Netzwerkgerät erstellt). In diesen VMs stehen alle Änderungen und Anwendungen, die in der Vorlage installiert werden, zur Verfügung, und selbst im Falle von Hintertüren ist kein Netzwerkzugang für eine Kompromittierung möglich.

Der Wettkampf um Windows

Die oben beschriebenen Funktionen bilden die Grundlage von Qubes und funktionieren sehr stabil, aber die Komplikationen beginnen mit Windows. Für die Integration von Windows muss das Set der Qubes Windows Tools (QWT) verwendet werden, das Treiber für die Arbeit mit Xen, den qvideo-Treiber sowie eine Reihe von Dienstprogrammen für den Informationsaustausch (Dateiübertragung, Zwischenablage) enthält. Der Installations- und Konfigurationsprozess ist auf der Projektwebseite ausführlich dokumentiert, daher teilen wir unsere Erfahrungen aus der Anwendung.

Die Hauptschwierigkeit besteht im Wesentlichen im Fehlen von Unterstützung für die entwickelte Toolchain. Die Hauptentwickler (QWT) scheinen nicht verfügbar zu sein, und das Integrationsprojekt mit Windows wartet auf einen leitenden Entwickler. Daher war es zunächst notwendig, die Funktionalität zu bewerten und ein Verständnis für die Möglichkeit der eigenständigen Unterstützung zu entwickeln, falls nötig. Am schwierigsten zu entwickeln und zu debuggen ist der grafische Treiber, der den Videoadapter und das Display emuliert, um ein Bild im gemeinsamen Speicher zu erzeugen, was es ermöglicht, entweder den gesamten Desktop oder direkt das Anwendungsfenster im Fenster des Hostsystems anzuzeigen. Im Verlauf der Analyse der Treiberfunktion haben wir den Code für den Build in einer Linux-Umgebung angepasst und das Debugging-Schema zwischen zwei Gast-Windows-Systemen getestet. In der Cross-Build-Phase haben wir einige vereinfachende Änderungen vorgenommen, hauptsächlich im Hinblick auf die "stille" Installation von Utilities, und auch die lästige Leistungseinbußen bei langfristiger Arbeit in der VM beseitigt. Die Ergebnisse haben wir in einem separaten Repository, wodurch wir kurzzeitig inspirieren den leitenden Entwickler von Qubes.

Der kritischste Schritt für die Stabilität des Gastsystems ist der Start von Windows. Hier kann man den vertrauten blauen Bildschirm sehen (oder auch nicht). Für die meisten identifizierten Fehler gab es verschiedene Umgehungsmöglichkeiten – die Ablehnung von Xen-Treibern für Blockgeräte, das Deaktivieren der Speicherbalance der VM, die Fixierung der Netzwerkeinstellungen und die Minimierung der Anzahl der Kerne. Unser Gastsystem wird auf vollständig aktualisiertem Windows 7 und Windows 10 installiert und betrieben (außer qvideo).

Beim Wechsel von einer physischen Umgebung in eine virtuelle Umgebung kann es zu Problemen mit der Aktivierung von Windows kommen, insbesondere wenn vorinstallierte OEM-Versionen verwendet werden. Diese Systeme nutzen eine Aktivierung, die auf Lizenzen basiert, die im UEFI des Geräts hinterlegt sind. Für eine ordnungsgemäße Aktivierung ist es notwendig, einen der ACPI-Bereiche des Host-Systems vollständig in das Gastsystem zu übertragen (SLIC-Tabelle) und einige weitere zu modifizieren, indem der Hersteller eingetragen wird. Xen ermöglicht die Anpassung des Inhalts zusätzlicher ACPI-Tabellen, jedoch nicht der grundlegenden. Ein Patch eines ähnlichen Projekts, OpenXT, der für Qubes angepasst wurde, bot eine hilfreiche Lösung. Diese Korrekturen waren nicht nur für uns nützlich und wurden in das Hauptrepository von Qubes sowie in die Libvirt-Bibliothek übertragen.

Eindeutige Mängel der Integrationsmittel von Windows sind das Fehlen von Audio-Unterstützung, USB-Geräten und die Schwierigkeiten bei der Medienverarbeitung, da es keine Hardware-Unterstützung für GPUs gibt. Dennoch steht der Nutzung von VMs für die Arbeit mit Office-Dokumenten nichts im Weg, und es hindert nicht an der Ausführung spezifischer Unternehmensanwendungen.

Die Anforderung, in den Offline-Modus oder den eingeschränkten Netzwerkmodus nach der Erstellung einer Windows-VM-Vorlage zu wechseln, wurde durch die Erstellung entsprechender Konfigurationen für Anwendungs-VMs umgesetzt. Die selektive Verbindung von externen Medien wurde ebenfalls mit den integrierten Mitteln des Betriebssystems gelöst — bei der Verbindung sind sie in der System-VM sys-usb verfügbar, von wo sie an die erforderliche VM „durchgereicht“ werden können. Der Desktop des Benutzers sieht ungefähr so aus.

Die finale Version des Systems wurde von den Nutzern positiv angenommen (wie es bei einer so komplexen Lösung möglich ist), und die integrierten Mittel des Systems ermöglichten eine Erweiterung der Nutzung auf mobile Arbeitsplätze mit Zugriff über VPN.

Abschließend

Die Virtualisierung insgesamt verringert die Risiken bei der Verwendung von nicht unterstützten Windows-Systemen — sie zwingt nicht zur Sicherstellung der Kompatibilität mit neuer Hardware, ermöglicht den Ausschluss oder die Kontrolle des Zugriffs auf das System über Netzwerke oder durch angeschlossene Geräte und schafft eine Umgebung für den einmaligen Einsatz.

Das Betriebssystem Qubes basiert auf dem Konzept der Isolation durch Virtualisierung und nutzt diese sowie andere Mechanismen zur Gewährleistung der Sicherheit. Viele sehen in Qubes in erster Linie den Wunsch nach Anonymität, doch es ist ein hilfreiches System sowohl für Ingenieure, die oft Projekte, Infrastrukturen und Zugriffsgeheimnisse kombinieren, als auch für Sicherheitsforscher. Die Trennung von Anwendungen, Daten und die Formalisierung ihrer Interaktion sind grundlegende Schritte zur Bedrohungsanalyse und zum Entwurf von Schutzsystemen. Diese Trennung hilft, Informationen zu strukturieren und das Risiko menschlicher Fehler — durch Eile, Müdigkeit usw. — zu minimieren.

Derzeit liegt der Schwerpunkt in der Entwicklung auf der Erweiterung der Funktionalität von Linux-Umgebungen. Die Version 4.1, die bald veröffentlicht wird, basiert auf Fedora 31 und wird die aktuellen Versionen der Schlüsselkomponenten Xen und Libvirt enthalten. Es ist erwähnenswert, dass Qubes von Fachleuten im Bereich der Informationssicherheit entwickelt wird, die stets schnell Updates bereitstellen, sobald neue Bedrohungen oder Fehler auftauchen.

Nachwort

Eine unserer entwickelten experimentellen Funktionen ermöglicht die Erstellung von VMs mit Gastzugang zur GPU basierend auf der Intel GVT-g Technologie. Dies eröffnet die Möglichkeit, die Fähigkeiten der Grafikkarte zu nutzen und den Anwendungsbereich des Systems erheblich zu erweitern. Zum Zeitpunkt der Erstellung dieses Artikels funktioniert diese Funktionalität für Testversionen von Qubes 4.1 und ist verfügbar auf github.

Quelle: habr.com