![[Illustration]](06-5-058-1.jpg)
Abbildung 1: SINA-Thin-Client-Lösung für den Multisessionbetrieb.
IT-Arbeitsplätze in Behörden oder Unternehmen sind in der überwiegenden Mehrzahl mit einem einzigen Betriebssystem ausgestattet, von dem gefordert wird, dass es alle Anforderungen an die tägliche Arbeit erfüllt. Diese meist vielfältigen Anforderungen sind häufig durch die konkreten Anwendungen definiert. Für IT-Arbeitsplätze mit Internetanbindung sind erhöhte Sicherungsmaßnahmen der lokalen Daten und Informationen gegen Zugriff von außen erforderlich. Bei Verarbeitung von Verschlusssachen (VS) ist durch die Vorschriftenlage zwingend eine physische Trennung von offenen und eingestuften sensitiven Netzen gefordert; das gilt selbst für unterschiedliche Einstufungsgrade. Eine Verarbeitung von VS bei gleichzeitiger Internetrecherche an einem IT-Arbeitsplatz ist ohne zugelassene Sicherungsmaßnahmen grundsätzlich verboten.
Zählt man alle möglichen Szenarien zusammen, so kommt man auf mindestens drei oder mehr Rechner mit eventuell redundanter Zusatzausstattung oder einem Keyboard-Video-Mouse-(KVM)-Switch. Mit einem so genannten Multi-Boot-Konzept ließe sich die Anzahl reduzieren – dies führt aber in der Praxis zu lästigen Wartezeiten und anderen Sicherheitsproblemen. Berücksichtigt man den Kostenfaktor und den Administrationsaufwand mit zentraler Softwareverteilung, so scheint diese Lösung wenig realistisch, genauso wie etwa die gemeinsame Nutzung von IT-Arbeitsplätzen für Spezialanwendungen.
Eine naheliegende Lösung der beschriebenen Problematik ist die Einführung eines Multisession-IT-Arbeitsplatzes: Eine Session ist durch die Nutzeroberfläche eines Betriebssystems definiert. Auf diesem IT-Arbeitsplatz sollte es möglich sein, durch eine einfache Tastenkombination oder eine applikative Steuerung in eine andere aktive Session zu wechseln, um dort etwa eine vorgesehene und auch zugelassene Tätigkeit zu verrichten.
Der für den Nutzer völlig transparente Wechsel der Arbeitsplatzumgebung zwischen den Sessions kann durch Virtualisierung der Hardware erreicht werden. Eine Virtualisierung der Hardware ermöglicht unterschiedlichen Betriebssystemen die gleichzeitige Koexistenz auf einem einzigen physischen IT-System. Jedes Betriebssystem einer Session findet eine wohldefinierte Hardwareumgebung vor, in der es sich installieren kann. Voraussetzung ist das Vorhandensein einer übergeordneten Instanz, die die Virtualisierung auf der physischen Hardware realisiert. Dieser Prozess ist auf gängigen IT-Systemen kompliziert und nicht immer ausreichend performant – wohl aber mit neuerer Hardware der führenden Prozessor- und Chiphersteller, die Virtualisierung als richtungsweisend entdeckt haben. Im Server-Bereich sind daher kommerzielle Lösungen schon weit verbreitet.
Die erste Generation von Multisession-Arbeitsplätzen für die Verarbeitung offener und eingestufter Sessions ist im BSI für die Sicherheitsarchitektur SINA (Sichere Inter-Netzwerk Architektur) [1] als Client-Server-Lösung entwickelt worden (s. Abb. 1). Auf verschiedenen Konsolen werden unterschiedliche Terminal-Sessions gestartet, die jeweils mit einem eigenen (modifizierten) X-Server über den monolithischen Linux-Kern (SINA-Linux) kommunizieren und sich an Remote-Terminal-Servern über eine VPN-Verbindung anmelden müssen. Eine lokale Datenspeicherung auf Massenspeichern ist aus Sicherheitsgründen nicht vorgesehen. Diese Lösung kommt ohne echte Virtualisierung der Hardware aus.
Bei den Sessions handelt es sich um einfache Terminal-Sessions, die als reine Applikationen zur Trennung des Informationsflusses mit eigenen X-Servern gestartet werden. Die X-Server gehören trotz eingeschränkter Rechte zur vertrauenswürdigen Code-Basis der Plattform. Die wesentlichen Sicherheitsfunktionen sind im monolithischen Betriebssystemkern (SINA-Linux) untergebracht. Konventionelle Thin-Client-Multisession-Lösungen kommen mit einer Instanz des X-Server aus.
Abbildung 1: SINA-Thin-Client-Lösung für den Multisessionbetrieb.
Im Folgenden wird die vom BSI entwickelte Virtualisierungslösung L4-Virtual-Machine (L4-VM) vorgestellt [2], die neben dem Multisession-Betrieb auch die VS-Verarbeitung an einem einzigen IT-Arbeitsplatz ermöglicht. Die zugrunde liegende Sicherheitsarchitektur wurde bereits in einem früheren Artikel beschrieben [3].
Die Pseudovirtualisierung in Abbildung 1 bietet nur ein begrenztes Maß an Flexibilität, da durch das Betriebssystem lediglich die Sicht auf das Dateisystem virtualisiert wird. Für eine Virtualisierung der Hardware benötigt man einen Virtuelle-Maschinen-Monitor (VMM). Bei einem VMM handelt es sich um eine Software, die Anforderungen eines Gastbetriebssystems an virtualisierte Systemressourcen oder virtualisierte Geräte auf physische Ressourcen und Geräte umsetzt. Diese Umsetzung kann das Durchreichen eines Zugriffs auf ein vorhandenes Gerät sein oder, im anderen Extrem, die reine Emulation eines nicht vorhandenen Geräts zu Simulationszwecken.
Diese spezielle Anwendung, die auf einem Hostbetriebssystem ausgeführt wird, also dem eigentlichen Betriebssystem der physischen Hardware, kann eine Virtualisierung der Hardware mit ganz unterschiedlichen Techniken realisieren. Der VMM ermöglicht unter anderem das Ausführen so genannter Legacy-Betriebssysteme auf einer Linux-Plattform. Die Kombination aus virtualisierter Hardware und Gastbetriebssystem bezeichnet man als virtuelle Maschine (VM). Es existieren unterschiedliche Virtualisierungstechniken, die im Folgenden genauer beschrieben werden.
Die Emulation ist die einfachste Form der Virtualisierung. Jede Codesequenz des Gastbetriebssystems wird abgefangen und, falls erforderlich, durch entsprechenden Code des VMM ersetzt. Dieses betrifft insbesondere Code, der Ring-0-Privilegien (s. u.) benötigt, um zum Beispiel auf die Hardware zuzugreifen oder geschützte Speicherbereiche zu adressieren. Beispiele, die diese Virtualisierungstechnik unter Open-Source-Lizenzen umsetzen, sind das Cross-Platform-Emulator-Projekt Bochs oder der Prozessemulator Qemu. Der zwangsläufig entstehende Overhead hat seinen Preis: Emulation ist die langsamste Form der Virtualisierung und sollte nur in kritischen Codeabschnitten bei Bedarf eingesetzt werden.
Unter Paravirtualisierung versteht man die direkte Modifikation eines Betriebssystems durch den Austausch spezieller Hardwarezugriffe durch passende Inter-Prozess-Kommunikation (IPC) und den direkten Zugriff auf Funktionen der Speicherverwaltung. Für Linux existiert ein versionsspezifischer Patch, der vor dem Kompilieren des Kernels eingespielt werden muss. Der Vorteil der Paravirtualisierung ist die Möglichkeit der weitgehend direkten Kommunikation des Gastbetriebssystems mit den Schnittstellen des Mikrokerns.
Hierbei ist sich der Gast "bewusst", dass er in einer virtuellen Umgebung ausgeführt wird und damit fällt auch weniger Übersetzungs-Overhead beim Ausführen des Gastes für den VMM an. Dieser Aspekt trägt zur hohen Leistungsfähigkeit des Gastbetriebssystems bei. Der Nachteil ist offensichtlich: Ein geeignetes Betriebssystem muss im Quellcode vorliegen und kann jeweils nur für einen speziellen Release-Stand paravirtualisiert werden. Beispiele, die diese Virtualisierungstechnik nutzen, sind die Open-Source-Projekte XEN, L4-Linux und User-Mode-Linux (UML).
Virtualisierung in Software ist bis heute die gängigste Methode der Virtualisierung. Dabei nutzt man das Vorhandensein der vier Privilegierungsstufen der Intel-Architektur "32-Bit" (IA32): In "normalen" Betriebssystemen läuft privilegierter Code im Ring-0 und Anwendungscode im Ring-3. Das Wechseln der Privilegierungsstufen, insbesondere die Eskalation von Privilegierungsstufen, ist nur durch einen von der Hardware kontrollierten Mechanismus möglich.
Softwarevirtualisierung besteht nun darin, den Ring-0 Code eines zu virtualisierenden Betriebssystems nicht zu ersetzen, sondern ihn auf einem weniger privilegierten Ring laufen zu lassen. In der Regel findet man in den entsprechenden Codeabschnitten nur wenige Instruktionen, die nur unter diesen Rechten ausgeführt werden müssen. Treten diese Instruktionen auf, kommt es zu so genannten Exceptions: Diese Routinen würden dann unter normalen Umständen einen Programmabbruch einleiten. Der VMM fängt die Exceptions ab und leitet entsprechende Maßnahmen für eine kontrollierte Programmfortsetzung ein. In der Regel wechselt jetzt der Kontext: Wird etwa eine bestimmte Hardware angesprochen, sorgt der VMM für die Weiterleitung der Anfrage an die zuständige Instanz. Diese Instanz ist autorisiert, mit dem Gerät zu kommunizieren. Ist der Zugriff erfolgt, wird die Kontrolle an den Gast zurückgegeben, das heißt Fortsetzung des Instruktionsflusses.
Die geeigneten Maßnahmen des VMM werden durch verschiedene Virtualisierungsmodi unterschieden; diese Modi werden anschließend genauer beschrieben. Beispiele, die diese Virtualisierungstechnik nutzen, sind die bekannten kommerziellen Produkte VMware, Microsoft Virtual PC/Server und VirtualBox (VBox). Als Open-Source-Lösung findet man OpenVZ, welche allerdings im Vergleich zu den kommerziellen Produkten eine eingeschränkte Funktionalität aufweist. Die Architektur einer VM mit VBox unter Linux ist in Abbildung 2 dargestellt. Die Trusted Computing Base (TCB) besteht hier aus dem Linux-Kern mit sämtlichen Gerätetreibern, dem Virtuelle-Maschinen-Monitor (VMM) und dem X-Server, der mit IOPL-3 privilegierte Instruktionen ausführen kann. Die VM läuft auf dem Host entweder in einem eigenen Fenster (Windowed-Mode) oder im Vollbild (Fullscreen-Mode). In der VM können vollständige Betriebssysteme installiert werden. Diese Architektur ist zugleich die Basis der zweiten Generation einer hochsicheren Multisession-Plattform des BSI, wie sie der SINA-Virtual-Workstation (SINA-VW) zugrunde liegt.
![[Illustration]](06-5-058-2.jpg)
Abbildung 2: Konventionelle VM-Architektur mit einem monolithischen Hostbetriebssystem (Linux) oder SINA-Linux für die SINA-VW.
Intel und AMD haben Erweiterungen der IA32 (mit 64-Bit-Erweiterungen EM64T), bekannt als Vanderpool, und AMD64-Architekturen, genannt Pacifica, in aktuelle Prozessormodelle integriert, um die Entwicklung von virtuellen Maschinen zu vereinfachen. Diese Erweiterungen werden vor allem Virtualisierungslücken schließen und einige Operationen, wie Kontextwechsel (World-Switch) durch Hardwareunterstützung beschleunigen. Durch die Einführung eines Root-Mode werden zusätzliche Privilegierungsschichten zur Verfügung gestellt, die von einer entsprechenden Instanz (Mikrokern/Hypervisor) genutzt werden können und höhere Privilegien als die Schichten des Non-Root-Mode innehaben. Für Gastbetriebssysteme stehen damit wieder alle konventionellen Privilegierungsstufen, einschließlich Ring-0, für die Nutzung bereit; dies ist gleichbedeutend mit der Tatsache, dass keine Modifikationen am Gastbetriebssystem vorgenommen werden müssen.
Primäres Sicherheitsziel ist die Integrität des Hostsystem – in keinem der folgenden Virtualisierungsmodi kann die Integrität des Hostbetriebssystems beeinträchtigt werden. Die Virtualisierungsmodi unterscheiden sich jedoch in der Wahrscheinlichkeit, dass Instabilitäten zur Laufzeit im Gastbetriebssystem auftreten können.
In diesem Modus wird der Gast-Code stets vor der Ausführung analysiert und neuer Code generiert. Da sich hierbei das Code-Layout ändert, ist prinzipiell eine vollständige Neuübersetzung des gesamten Codes notwendig. Der rekompilierte Gast-Code wird im Ring-3 des Prozessors ausgeführt und die unterschiedlichen Privilegierungsstufen im Gast-Code werden durch den Recompiler emuliert. Die Rekompilation stellt durch ihren Performance-Nachteil vorwiegend eine immer verfügbare "Fallback-Lösung" dar und wird zum Beispiel zur Virtualisierung von "Real-Mode"-Code verwendet oder falls in einem anderen Virtualisierungsmodus ein nicht unterstützter Zustand detektiert wird (ein Fehler oder wenn ein in der Praxis sehr unwahrscheinlicher bzw. nicht performance-kritischer Fall entdeckt wird, der aus Gründen der Vereinfachung in dem jeweiligen Modus nicht unterstützt wird).
Theoretisch bietet diese Art der Virtualisierung keine "Löcher", was jedoch dadurch eingeschränkt wird, dass man das komplette Verhalten der CPU nachbilden muss, was äußerst komplex ist. Da der generierte Code in einer geschützten Umgebung im User-Modus abläuft, bestehen keine weiteren Sicherheitsrisiken. Dieser Virtualisierungsmodus wird vorwiegend bei vollständiger Virtualisierung in Software verwendet.
Hierbei wird Ring-3-Code des Gastsystems direkt auf der CPU ausgeführt und eine dem nativen System sehr ähnliche Umgebung geschaffen. Es gibt einige Virtualisierungslöcher der IA32-CPUs, die jedoch in der Praxis relativ unbedeutend sind und wiederum nicht die Sicherheit des Hostsystems kompromittieren können. Da der Gast-Code in einer geschützten Umgebung im User-Modus abläuft, bestehen keine weiteren Sicherheitsrisiken.
Bei diesem Modus wird zusätzlich zum Gast-User-Code auch der Gast-Kernel-Code (oder zumindest Teile davon) direkt ohne Rekompilation ausgeführt. Hierzu wird der Ring-1 der CPU verwendet, der – wie auch Ring-3 – nicht privilegiert ist. Den einzigen Unterschied zwischen Ring-1 und Ring-3 stellt die Möglichkeit von Ring-1 dar, auf Kernspeicher zuzugreifen sowie auf schreibgeschützten Speicher schreibend zuzugreifen. Ersteres wird dadurch verhindert, dass es einem Gastsystem nicht gestattet ist, unkontrollierte Änderungen an seinen Seitentabellen vorzunehmen: Beim Versuch eine geladene Seitentabelle zu modifizieren oder eine neue Seitentabelle zu laden, erhält der VMM die Kontrolle und hat Gelegenheit, die Änderung zu überprüfen.
Seit dem 80486 steht mit dem WP-Flag (Write Protect) eine Möglichkeit zur Verfügung, auch Ring-1 und Ring-0 den Schreibzugriff auf schreibgeschützten Speicher zu verbieten. Dieses Flag wird vom VMM stets vor der Ausführung von Gast-Code gesetzt. Im Ring-0 gibt es bei IA32-CPUs eine große Anzahl an Virtualisierungslücken. Daher ist diese Technik sehr komplex und auch fehleranfällig. Allerdings bestehen die Risiken bei allen möglichen Szenarien ausschließlich darin, dass das Gastsystem fehlerhaft arbeitet beziehungsweise in den meisten Fällen abstürzt.
Nach diesen technischen Betrachtungen stellen sich für das Multisession-Konzept einige wichtige Fragen, deren Antwort im zweiten Teil dieses Beitrags in der folgenden <kes> gegeben werden sollen. Wie wird der unkontrollierte Zugriff aus der VM oder aus dem VMM auf Hardware-Ressourcen sicher verhindert? Wie kann verhindert werden, dass Schadsoftware, zum Beispiel über das Ausführen aktiver Inhalte innerhalb des Gastbetriebssystems, direkten Zugriff auf etwa Netzwerkkarten oder Massenspeicher erhält? Ein VMM besitzt (noch) nicht die "Intelligenz", bösartige von regulären Anforderungen eines Gastbetriebssystems zu unterscheiden. Aus diesem Grund sind Gastbetriebssysteme grundsätzlich als nicht vertrauenswürdig einzustufen. Diese Feststellung ist unabhängig von etwaigen zusätzlichen Sicherheitsmaßnahmen innerhalb des Gastes.
Eine geeignete Sicherheitsstrategie ist die Isolierung der Gastbetriebssysteme von allen anderen Systemkomponenten. Das Durchbrechen der Isolierung kann nur kontrolliert über den VMM über wohldefinierte Schnittstellen zwischen der VM und dem VMM und vom VMM zum Hostbetriebssystem erfolgen. Die VM greift nie direkt auf physische Geräte zu. Der Zugriff erfolgt immer über virtualisierte Hardware, die vom VMM kontrolliert und bei Bedarf sicher auf physische Hardware oder auf andere im System bereitgestellte Hardwareabstraktionen weitergeleitet wird.
Fortsetzung in der nächsten <kes>.
![[externer Link]](../../../../images/link.gif)
www.bsi.bund.de/fachthem/sina
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2006#5, Seite 58
| 