µSINA – eine Mikrokern-basierte Systemarchitektur für sichere Systemkomponenten

Ordnungsmerkmale

erschienen in: <kes> 2003#3, Seite 42

Rubrik: BSI Forum

Schlagwort: Mikro-Kern-Architektur

Best Papers Award

Dieser Beitrag errang auf dem 8. Deutschen IT-Sicherheitskongress des BSI im Mai 2003 einen Best Papers Award. Die Begründung des Programmbeirats lautete: Der Beitrag gibt einen guten Überblick über µSINA, die Darstellung ist klar, die Beispiele Netzwerk-Protokollstack und Gerätetreiber/DMA sind gut dargestellt. Der Artikel ist nicht nur technisch interessant, sondern beinhaltet auch eine gelungene Verbindung von Theorie und Praxis.

Zusammenfassung: Im Rahmen des Forschungsprojekts µSINA erfolgt die Entwicklung einer Betriebssystemarchitektur für Systeme mit sehr hohen Sicherheitsanforderungen. Diese Architektur weist eine überschaubare Komplexität auf und ermöglicht dadurch eine effiziente Evaluierung. Die Systemarchitektur von µSINA wird exemplarisch für ein Sicherheitsgateway auf Mikrokernbasis umgesetzt, dessen Komponenten in separaten Adressräumen ablaufen und dadurch voreinander geschützt sind. Diese können ausschließlich über einen Kernmechanismus miteinander kommunizieren. Auf diese Weise wird unkontrollierte Kommunikation unterbunden und die Auswirkung von Fehlern in einzelnen Komponenten eingeschränkt. Die so entkoppelten Komponenten lassen sich unabhängig voneinander evaluieren.

Autor: Von Christian Helmuth und Dr. Andreas Westfeld, TU Dresden, sowie Dr. Michael Sobirey, secunet AG

In den vergangenen drei Jahren entstand, basierend auf einem Konzept des BSI im Rahmen eines Entwicklungsauftrages mit der Sicheren Inter-Netzwerk-Architektur SINA [17] eine modulare, flexibel skalierbare Architektur für eine sichere Verarbeitung und Übertragung von Verschlusssachen (VS) sämtlicher nationaler und wichtiger internationaler Geheimhaltungsstufen. Die in SINA integrierten Sicherheitstechnologien umfassen unter anderem IPSec (VPN), sowohl software- als auch hardwarebasierte Kryptographie, eine Public-Key-Infrastruktur (PKI), Smartcards, sicheres Löschen, IP-Paketfilter, ein kombiniertes Betriebssystem- und (rechnerspezifisches) Netzaudit sowie Intrusion Detection and Response. 2002 erreichten die ersten drei Basiskomponenten, der SINA Thin Client, die SINA Box – ein IPSec-Gateway [15] – und das dazugehörige SINA Management, den finalen, spezifizierten Funktionsumfang.

Den beiden erstgenannten Komponenten liegt SINA-Linux zugrunde, eine extrem minimalisierte und funktional gehärtete Systemplattform, deren Sicherheit aufwändig analysiert wurde. Während auf Prozessebene vorrangig extensiv minimalisiert wurde, konzentrierten sich auf Kernebene die Anstrengungen auf Absicherung beziehungsweise Abgrenzung der unterschiedlichen Datenströme gegeneinander. Der Codeumfang der SINA Box beläuft sich beispielsweise auf (komprimierte) 5 MByte und ermöglicht damit auch das Booten von Flash-Speichermedien.

Ziel des Forschungsprojektes µSINA ist es, eine vereinfachte Variante der SINA Box auf eine gegenüber dem bislang verwendeten monolithischen Betriebssystem nochmals signifikant schlankere und damit besser evaluierbare Systemplattform abzubilden, prototypisch umzusetzen und zu erproben. Außerdem wird eine noch differenziertere Separierung von Prozessen und Daten(strömen) angestrebt. Grundlage hierfür ist eine mikrokernbasierte Systemplattform. Die genannte Variante der SINA Box wird schrittweise auf diese Systemplattform portiert.

Mikrokerntechnologie und Sicherheit

Während im Kern eines monolithischen Betriebssystems alle grundlegenden Systemdienste integriert sind, wird beim mikrokernbasierten Ansatz insbesondere dieser Teil minimiert. Alle Dienste werden in Mikrokernserver ausgelagert, die in unabhängigen Adressräumen ablaufen. Die Mikrokernserver nutzen die gleichen Kernmechanismen wie Nutzerprogramme. Dadurch können Programmierfehler oder fehlerhafte Konfigurationen von Systemdiensten und Nutzerprogrammen gleichermaßen nicht manipulierend auf den Kern und andere Systemkomponenten übergreifen. Tritt in einer Komponente ein Problem auf, so kann diese umkonfiguriert und neu gestartet werden, ohne dass ein Neustart des gesamten Betriebssystems erforderlich ist. Das erweist sich als hilfreich in Anwendungsbereichen, die eine hohe Verfügbarkeit erfordern und erhöht sowohl die Sicherheit als auch die Robustheit des Gesamtsystems. Dies wird durch den sehr schlanken Kern im privilegierten Prozessormodus und Betriebssystemdienste in separaten Adressräumen erreicht.

Bisherige Mikrokerne (z. B. [1]) erreichten nur geringe Akzeptanz, da sich die Leistung eines Großteils der bekannten Implementierungen als unzureichend erwies. Dies beeinträchtigt vor allem die Flexibilität, da wichtige Kernmechanismen aufgrund schlechter Performance nicht genutzt werden. Eine gängige Praxis für Mikrokerne der ersten Generation war es, entgegen dem minimalisierenden Ansatz, Dienste in den Kern zu reintegrieren, obwohl der Mikrokernansatz nicht die Ursache des Leistungsproblems ist [2].

Ergebnis eines neuen Vorstoßes in Richtung "echter" Mikrokerne sind die Vertreter der zweiten Generation. Diese erreichen aufgrund sorgfältiger Analyse der kritischen Pfade innerhalb des Kerns eine weitaus höhere Leistung und beschränken sich dabei auf ein Minimum an Kernmechanismen. Der Mikrokern Fiasco [3] der TU Dresden ist ein Kern der zweiten Generation und implementiert die L4-Schnittstelle [4]. Er zeichnet sich durch die Programmierung in einer Hochsprache (C++) und sehr gute Interprozesskommunikation-(IPC-)Performance aus.

Vergleich zu Multilevel Security und Domain Type Enforcement

Multilevel Security (MLS) oder das Bell-LaPadula-Modell [5] organisieren Daten und Anwendungen, welche verschiedenen Sicherheitsstufen angehören, auf Sicherheits- oder Gefährdungsebenen. Der Austausch von Daten ist festen Regeln unterworfen (Mandatory Access Control), die nicht vorsätzlich oder versehentlich umgangen werden können:

Da alle Aktivitäten diesen Regeln unterworfen sind, ist es auch Trojanischen Pferden nicht möglich, Daten in niedrigere Sicherheitsstufen zu transferieren. In der Praxis sind für MLS-Systeme vor allem verdeckte Kanäle problematisch, da verschiedene Sicherheitsstufen auf gemeinsame Ressourcen zugreifen (z. B. Dateisystem, Geräte) und somit zum Transfer von Informationen nutzen können.

Seit dem Ende der 80er-Jahre fanden MLS-Systeme vor allem im militärischen Bereich praktische Umsetzungen. Ein Beispiel ist SCOMP, eine um MLS erweiterte Version des Betriebssystems MULTICS. Gegenwärtig wird MLS vor allem in modifizierten Versionen von Unix, wie etwa V/MLS von AT&T oder SGIs Trusted IRIX, angewendet.

Die von MLS verlangte Einteilung in Sicherheitsstufen erwies sich als unflexibel und schwierig im praktischen Einsatz [16]. Neben anderen Weiterentwicklungen ist besonders das Domain-Type-Enforcement interessant, das neben der Vertraulichkeit auch die Integrität der Daten betrachtet. Prozesse werden hierbei Domänen und Objekte (u. a. Daten-) Typen zugeordnet. Eine Zugriffsmatrix – die Domain Definition Table (DDT) – regelt die Zugriffe von Domänen auf Typen. So wird jeder Aktivität explizit der Zugriff auf unbedingt benötigte Betriebsmittel gestattet (Prinzip der geringstmöglichen Privilegierung). Der gemeinsame Zugriff von Prozessen auf globale Betriebsmittel kann hiermit auf ein Minimum reduziert werden. Dadurch werden die Möglichkeiten für verdeckte Kanäle drastisch eingeschränkt.

Das Domain-Type-Enforcement wird gegenwärtig kommerziell in Firewalls, wie z. B. Sidewinder, eingesetzt [6, 7]. Als Basis dient hier LOCK (Logical Coprocessing Kernel), welcher seit 1987 entwickelt wird [8]. Die Durchsetzung der Zugriffsrechte wird durch den darauf aufbauenden Referenzmonitor SIDEARM (System Independent Domain Enforcing Assured Reference Monitor) als Systemkomponente erzwungen. Der Entwurf von SIDEARM kombiniert Software und spezielle Hardware.

µSINA setzt das Prinzip der geringstmöglichen Privilegierung durch den Einsatz eines Mikrokerns auf Standard-PC-Hardware um. Die Kommunikation zwischen einzelnen Systemkomponenten findet per Interprozesskommunikation (IPC) und somit durch den Mikrokern kontrolliert statt.

Architektonischer Ansatz

Die Systemarchitektur von µSINA setzt eine sichere Systemplattform als Basis für anwendungsspezifische Dienste voraus. Hierbei wird die Hardware des Systems als vertrauenswürdig angesehen, das heißt alle Geräte verhalten sich entsprechend ihrer Spezifikation und beinhalten keine darüber hinausgehende (versteckte) Funktionalität. Diese Annahme gilt für Standardgeräte wie CPU und Speicher genauso wie für Erweiterungskarten, beispielsweise Netzwerkadapter. Weitere grundlegende Anforderungen an die Systemplattform für µSINA sind:

Um diese Anforderungen zu erfüllen, wird in µSINA ein mikrokernbasierter (und kein monolithischer) Ansatz für die Architektur des Betriebssystems verfolgt. Somit werden alle Komponenten des Systems durch die vom Mikrokern implementierten Adressraumgrenzen separiert. Adressräume bilden auf Hardwareebene die Seiten des virtuellen Adressraums der Komponente auf physische Seiten des Hauptspeichers ab. Diese Abbildung wird durch die TLB-Hardware (Translation Lookaside Buffer) der CPU und Seitentabellen implementiert, deren Modifikation dem Mikrokern vorbehalten ist.

Die Änderung der Adressabbildung kann nur mithilfe des Mikrokerns durchgeführt werden. Somit sind alle Komponenten des Systems durch Adressraumgrenzen untereinander geschützt und können diese Grenzen ausschließlich mithilfe der vom Kern angebotenen und kontrollierten Mechanismen überwinden.

Der Nachrichtenmechanismus des Mikrokerns wird mittels IPC oder Message Passing realisiert. Der Austausch von Botschaften findet nur dann statt, wenn beide Kommunikationspartner diesem zustimmen. Außerdem bietet der Mikrokern einen Mechanismus zur Kontrolle des Message Passings (= IPC, z. B. [9]). Mithilfe dieses Mechanismus ist es möglich, die Kommunikation auf bestimmte Partner einzuschränken. Die so kontrollierten Komponenten erhalten folglich nur die zur Erfüllung ihrer spezifischen Aufgabe nötigen kommunikationsrelevanten Privilegien.

Eine Laufzeitumgebung bestehend aus Mikrokernservern verwaltet die Systemressourcen mithilfe der Mechanismen des Kerns (s. Abb. 1). Die Ressourcen sind im Einzelnen Hauptspeicher, Adressräume und Threads sowie Ein-/Ausgabe-Ressourcen (I/O-Ports, Memory Mapped I/O-Bereiche, Interrupts). Die Ressourcenmanager setzen auf Grundlage der vom Mikrokern angebotenen Mechanismen eine systemspezifische Ressourcen-Vergabepolitik durch und sind somit ein Teil der Systemplattform und als vertrauenswürdig einzustufen. Zur Laufzeitumgebung zählt auch ein sicherer Namensdienst, der symbolische Dienstnamen auf eindeutige Thread-Identifikatoren abbildet. Auf der Grundlage dieser Plattform werden nun die weiterführenden Dienste für µSINA in separaten Komponenten umgesetzt.

[Illustration]
Abbildung 1: Die Systemarchitektur von µSINA

Exemplarische Umsetzung

Nachdem die Entwicklung der Systemplattform abgeschlossen ist, besteht die zweite Aufgabe in µSINA in der schrittweisen Portierung einer Variante der SINA Box auf diese Plattform. Dieses Sicherheitsgateway trennt physisch zwei Netze, indem es für jedes der Netze einen Netzwerkadapter enthält und die Netzwerkpakete mithilfe der Systemsoftware von einem Adapter zum anderen weiterleitet. Die beiden Netze werden als roter und schwarzer Bereich aufgrund der Sichtbarkeit der sensitiven Daten bezeichnet. So sind die sensitiven Daten im roten Bereich nicht gegen Zugriffe oder Veränderungen geschützt, während diese im schwarzen Bereich zur Einhaltung von Vertraulichkeit und Integrität verschlüsselt ("geschwärzt") sind und einen Authentifikationscode (MAC) tragen.

Innerhalb des Sicherheitsgateways existieren verschiedene Komponenten, die Daten aus dem roten und schwarzen Bereich verarbeiten. Die Komponenten des Systems laufen in separaten Adressräumen ab, was unkontrollierte gegenseitige Beeinflussung ausschließt. Es muss nun entschieden werden, welche Komponenten des Systems evaluiert werden müssen, das heißt vertrauenswürdig sind.

Zur Einhaltung der Schutzziele Vertraulichkeit und Integrität wird gefordert, dass Daten, welche vom roten in den schwarzen Bereich gelangen, kryptographisch gegen Einsicht und Manipulation durch potenzielle Angreifer geschützt sind. Das bedeutet, dass Komponenten, welche Daten beider Bereiche verarbeiten, vertrauenswürdig sein müssen, also Gegenstand der Evaluierung sind.

Wenn eine Komponente nur schwarze Daten verarbeitet und keine Möglichkeit hat, direkten Einfluss auf andere Systemkomponenten zu nehmen, kann diese von der Evaluation ausgeschlossen werden. Die vorgestellte Architektur setzt dies mittels Adressräumen und IPC-Redirection durch.

Die Verarbeitung von roten Daten ist sicherheitskritisch und muss vertrauenswürdig durchgeführt werden. Eine Evaluation aller Komponenten, welche rote Daten verarbeiten, würde diese Anforderung erfüllen. Da aber möglichst wenige Komponenten evaluiert werden sollen und der Anteil der sicherheitskritischen innerhalb des Gateways groß ist, werden diese nochmals genauer betrachtet.

In [10] wird das Tunneling als eine Technik zur Minimierung der Anzahl der Komponenten in der Systemplattform beschrieben. Hier wird vorgeschlagen, zum Beispiel Dateisysteme nicht als Bestandteile einer sicheren Systemplattform zu betrachten und von einer Evaluation auszuschließen, wenn durchgesetzt wird, dass diese nur verschlüsselte Daten verarbeiten. Das Tunneling wird als Technik definiert, die es erlaubt, "Software zu verwenden, welche eine verlangte Eigenschaft nicht erfüllt, und diese Eigenschaft in einer zusätzlichen Schicht durchzusetzen".

Eine Möglichkeit diesen Ansatz fortzuführen ist, Komponenten vollständig vom restlichen System zu isolieren (Kapselung), sodass keine ungewollte Kommunikation möglich ist. Allgemein muss eine solche Komponente nur minimale Handlungsfreiheit erhalten. Diese Forderung bezeichnet man als Prinzip der geringsten Privilegierung. Auf diese Weise ist eine kryptographische Behandlung der verarbeiteten Daten nicht nötig, da Absender und Empfänger festgelegt sind.

Die Systemarchitektur von µSINA bietet alle nötigen Mittel, um diese Anforderungen zu erfüllen: Adressräume und kontrollierte IPC. Es ist somit möglich, Inseln zu schaffen, auf denen nicht vertrauenswürdige Komponenten rote Daten verarbeiten.

Ein Problem sind verdeckte Kanäle (Covert Channels) zwischen Komponenten des Systems, welche mit der vorgestellten Technik nicht ausgeschlossen werden können. Eine Voraussetzung für verdeckte Kanäle sind gemeinsam benutzte Ressourcen, die man, da die Komponenten auf einem System ablaufen, nicht vollständig vermeiden kann.

Netzwerk-Protokollstack

Die Implementierung der Netzwerkprotokolle wird als Stack realisiert, sodass Protokolle der Transportschicht (TCP, UDP) auf der Netzwerkschicht (IP, IPSec) aufbauen und Netzwerkpakete durch diese und weitere Schichten "wandern". IPSec ist ein wichtiger Bestandteil der Netzwerksoftware; in ihm werden sowohl schwarze als auch rote Daten verarbeitet. Die Pakete werden auf dem Weg durch den Stack kryptographisch zum Schutz von Vertraulichkeit oder Integrität behandelt. Diese sicherheitskritische Bestandteile müssen evaluiert werden.

Die Komplexität aktueller Implementierungen ist sehr hoch. So umfassen beispielsweise die IP-spezifischen Module innerhalb des Linuxkerns (Version 2.4.20) etwa 80 000 Zeilen C-Code. Deshalb und aufgrund der Tatsache, dass von zukünftigen Entwicklungen leichter profitiert werden kann, ist die Wiederverwendung einer bestehenden Umsetzung einer Neuimplementierung vorzuziehen.

Um den Umfang des Quellcodes so gering wie möglich zu halten, bieten sich unter diesen Voraussetzungen zwei Möglichkeiten: Eine Zergliederung der bestehenden Software in mehrere sicherheitskritische und -unkritische Komponenten oder die Verwendung von zwei Netzwerkstacks mit einer Brückenkomponente.

[Illustration]
Abbildung 2: Beispielszenario zur Zergliederung des Netzwerkstacks

Zergliederung in sicherheitskritische und -unkritische Komponenten

Für die Zergliederung müssen die Komponenten im bestehenden System identifiziert und anschließend gekapselt werden. Als Beispiel soll das in Abbildung 2 dargestellte Szenario dienen:

Von diesen Komponenten ist das Routing für die Vertraulichkeit und Integrität der Daten unkritisch, da hier nur die Header (Verkehrsdaten) des Pakets verarbeitet werden. Die in Abbildung 2 dargestellte Zergliederung schließt das Routing von den zu evaluierenden Komponenten aus. Genauso können nun weitere Komponenten betrachtet werden.

Diese Vorgehensweise differenziert die Netzwerksoftware in mehrere kleine Module und erlaubt die spezifische Verringerung des zu evaluierenden Quelltextes. Es ist anzumerken, dass hier eventuell komplexere Schnittstellen eingeführt werden als jene, die Bestandteil der Originalimplementierung sind. Außerdem zieht eine starke Zergliederung die Einführung neuer Schnittstellen innerhalb bestehender Module nach sich, sodass die Wiederverwendbarkeit der neuen Komponenten bei Aktualisierungen der zugrunde liegenden Originalimplementierung nicht gewährleistet sein muss. Modulinterne Änderungen des Originals sind sehr wahrscheinlich, auch wenn die Schnittstelle unverändert bleibt.

Verwendung von zwei Netzwerkstacks und einer Brückenkomponente

Eine Möglichkeit, fest definierte Schnittstellen beizubehalten, ist es, die Netzwerkprotokollfunktionen zu duplizieren und zwei komplette Stacks in einem System zu verwenden. Kommunikation zwischen diesen kann nur über eine "Brücke" stattfinden, die eine IPSec-konforme Ver- und Entschlüsselung der Netzwerkpakete durchsetzt.

[Illustration]
Abbildung 3: Realisierung der Netzwerkprotokolle mit Brückenkomponente

Bei diesem Ansatz ist gewährleistet, dass jeder Stack nur Daten eines Bereiches – rot oder schwarz – verarbeitet. Gegenstand einer Evaluierung ist hierbei nur die Brückenkomponente, die teilweise von bestehenden IPSec-Implementierungen abgeleitet sein wird. Die Netzwerkstacks müssen so angepasst werden, dass die Daten (Netzwerkpakete) auch von zwischengelagerten Ebenen nach außen gegeben werden. Die Brücke verbindet die beiden Teil-Stacks zu einem kompletten Netzwerk-Protokollstack (s. Abb. 3).

Es stellt sich nun die Frage, wie angreifbar diese Lösung ist. Da beide Netzwerkstacks nicht evaluiert werden, sind diese durch potenziell eingeschleuste Trojanische Pferde gefährdet. Sie allein bieten somit keine gegenüber dem Originalsystem gesteigerte Sicherheit. Die Brückenkomponente ist Gegenstand einer Evaluation und somit gegen bekannte Angriffe immun. Weiterhin wird die gesamte Kommunikation zwischen den Stack-Komponenten kryptographisch behandelt und potenzielle Trojanische Pferde haben deshalb keine Möglichkeit für den offenen Austausch von Informationen. Durch die Brücke wird auch bei kompromittierten Protokollimplementierungen durchgesetzt, dass keine sensitiven Daten in die unteren Schichten des Netzwerkstacks gelangen und Vertraulichkeit sowie Integrität geschützt sind.

Verdeckte Kanäle wurden von den Autoren nicht näher betrachtet, können aber keinesfalls ausgeschlossen werden. Innerhalb der Brückenkomponente können bekannte Techniken eingesetzt werden, zum Beispiel Pump [11], um gemeinsam benutzte Betriebsmittel der Netzwerkstacks zu entkoppeln und deren Kommunikationsinhalte als Trägermedium auszuschließen.

Gerätetreiber

Die Ansteuerung von Ein-/Ausgabe-Geräten trägt aufgrund der Vielfalt der verfügbaren Chipsätze und Hersteller beträchtlich zur Komplexität aktueller Betriebssysteme bei. Daher würde eine Verlagerung der Gerätetreiber aus der Systemplattform in eine möglicherweise nicht vertrauenswürdige Komponente einen großen Beitrag zur Senkung der Komplexität der Systemsoftware leisten.

In diesem Zusammenhang muss die Funktionsweise der Ein-/Ausgabe-Geräte und der Ansteuerungssoftware auf der (PC-) Zielplattform genauer betrachtet werden. Hier greifen die PCI-Adapterkarten häufig direkt auf den Hauptspeicher zu (Direct Memory Access, DMA), um die CPU zu entlasten (s. Abb. 4).

[Illustration]
Abbildung 4: Busmaster-DMA-Zugriff auf physische Adressen

Diese Vorgehensweise verursacht aber ein Sicherheitsrisiko, das aus der Verwendung der beschriebenen Busmaster-DMA-Controller resultiert. Da diese nicht an die Adressabbildung der CPU gebunden und frei programmierbar sind, ist es Komponenten des Systems (z. B. Gerätetreibern) mithilfe von DMA möglich, über den Umweg der Geräteprogrammierung die vom Mikrokern durchgesetzten Adressraumgrenzen zu durchbrechen. Eine fehlerhaft programmierte Netzwerkkarte könnte beispielsweise auf den physischen Speicher zugreifen und dabei Teile des Mikrokerns überschreiben, ohne dass die CPU dabei eine Schutzverletzung feststellt.

Dieses Problem wird auch in [10] diskutiert, und es werden zwei Lösungsansätze vorgeschlagen, um Gerätetreiber außerhalb der Systemplattform zu implementieren: