© double click, Fotolia.com

Minix 3 gilt in einigen Belangen als geistiger Vorfahr von Linux. Dennoch flammt bisweilen immer noch ein Streit über Microkernel, Sicherheit und Feature-Umfänge auf. Tanenbaum-Schüler und Krypto-Experte Professor Rüdiger Weis stellt sein Lieblingsbetriebssystem vor.

Seine Entwickler haben Minix 3 mit dem Ziel entworfen, sicherer und zuverlässiger als vergleichbare Posix-Systeme zu sein [1]. Die Version 3 steht unter einer BSD-nahen Open-Source-Lizenz und beansprucht, sich sowohl für die Lehre als auch für den praktischen Einsatz zu eignen. Es lassen sich damit beispielsweise eingebettete Systeme entwickeln, die hinsichtlich Sicherheit und Zuverlässigkeit anderen Systemen überlegen sind [2]. Gründe genug, einen Blick auf die Reinkanation des Linux-Vorfahren zu werfen (siehe Kasten “Minix und Linux”) – zumal sich in einigen Szenarien Minix und Linux gut ergänzen.

Entworfene Unsicherheit

Sicherheitsprobleme aktuell verwendeter Betriebssysteme – dazu gehören Windows, aber auch Linux – rühren von Designfehlern her. Die Fehler erbten sie zu großen Teilen von ihren Vorgängern aus den 1960er Jahren. Die meisten von ihnen lassen sich darauf zurückführen, dass Entwickler nicht perfekt arbeiten. Menschen machen Fehler. Wünschenswert wäre, wenn sie die Anzahl und Auswirkung von Fehlern zu reduzieren suchten. Sie waren jedoch viel zu oft bereit Sicherheit und sauberes Design der Geschwindigkeit zu opfern. Minix-Vater Tanenbaum nennt das in seinen Publikationen einen “faustischen Pakt”.

Es überrascht wenig, dass die Fehlerquote wächst, wenn die Komplexität der Programme zunimmt. Tanenbaum selbst schreibt in seinem Editorial in dieser Ausgabe von mindestens einem bis zu zehn Fehlern in 1000 Programmzeilen. Windows XP allein besteht aus 50 Millionen Codezeilen. Somit müssen Anwender mit 50000 bis einer halben Million Fehlern rechnen. Wer eine Seite pro Fehlerbeschreibung annimmt, benötigt selbst im günstigen Fall zur Fehlerdokumentation ein kleines Bücherregal.

2007 berichtete ein Mitarbeiter des Microsoft Security Response Center (MSRC), dass sein Arbeitgeber in Folge einer kryptographischen Schwachstelle viele Tausend Funktionen anpassen musste. Zum Zeitpunkt des Vortrags warteten trotz erheblichen Aufwands noch Hunderte Sicherheitslücken allein in diesem Problemfeld auf ihre Sanierung [6].

Bei der Entwicklung aktueller Betriebssysteme fanden Sicherheitsaspekte so gut wie keine Beachtung. Sicherheitsnachrüstungen (SE Linux, App Amor) erschweren zwar einige Angriffsformen, erhöhen aber erneut die Systemkomplexität. Viele Experten vertreten gar die Position, dass Nachrüsten und Patchen so viele Probleme schaffen, wie sie lösen. In ihrem Standardwerk zur Kryptographie fordern Bruce Schneier und Niels Ferguson daher einen kompletten Neuentwurf der IT einschließlich der Betriebssysteme und Programmiersprachen [7].

Gefahr durch Treiber

Zusätzlich zu der schieren Größe bringt die monolithische Konstruktion strukturelle Probleme mit sich: Jeder Fehler ist in der Lage, das gesamte System zu gefährden. Dass aktuelle Betriebssysteme nicht dem “Principle Of Least Authority” (POLA) folgen, stellt einen grundlegenden Designfehler dar. Vereinfacht gesagt sollten Entwickler Systeme nach dem POLA derart in Module einteilen, dass ein Fehler in einem Modul nicht die Sicherheit und Stabilität von anderen Modulen in Mitleidenschaft zieht. Sie sollten außerdem jedes Modul nur mit den Rechten ausstatten, die es unbedingt benötigt, um seine Aufgaben zu erfüllen. Das gilt besonders für Gerätetreiber.

Das ständige Wachstum der Betriebssystemgröße rührt von der Integration immer neuer Treiber her. Monolithische Systeme integrieren Gerätetreiber in den Kernel. Dies bedeutet, dass Treiberfehler die Stabilität des gesamten Systems gefährden. Das lässt sich mit einem Fehler in einer Musikdatei im Autoradio vergleichen, der den Motor in Mitleidenschaft zieht. Die Automobilindustrie, munkeln Pessimisten, arbeite jedoch bereits daran.

Insbesondere Closed-Source-Treiber gefährden die Systemsicherheit. Tanenbaum vergleicht deren Einsatz damit, ein versiegeltes Paket von einem Fremden entgegenzunehmen und damit ein Flugzeug zu besteigen. Der Wissenschaftler sagt: “Es ist kein Wunder, dass Fluglinien so ein Verhalten nicht empfehlen.”

Transparente Architektur

Minix ist das wohl am besten dokumentierte Betriebssystem. Das Minix-Buch von Tanenbaum und Woodhull ist weltweit das Referenzwerk für praktisch orientierte Betriebssystemvorlesungen [4]. Zu den Neuerungen und laufenden Forschungen gibt es zahlreiche Publikationen auf der Homepage von Minix 3 [8].

Minix erfüllt den Posix-Standard IEEE 1003.2-1996. Entwickler haben bereits viele Unix-Programme portiert. Der ursprüngliche Kernel besteht aus etwa 3700 Programmzeilen und bootet in ungefähr 5 Sekunden auf einer mit 4,77 MHz getakteten 8088-CPU. Minix 3 bietet durch seine Architektur eine ganze Reihe von Vorteilen gegenüber weitverbreiteten Systemen ohne Microkernel.

Fehlende Übersicht

Monolithische Betriebssysteme wie Windows und Linux bestehen hingegen aus vielen Millionen Codezeilen. Programme dieser Größe sind weder einfach zu überblicken noch ohne große Mengen von Programmierfehlern zu implementieren. Der Lehrplan vieler Hochschulen enthält Minix 3 im Rahmen einer einsemestrigen Vorlesung über Betriebssysteme. Die wenigen Tausend Programmierzeilen von Minix haben mehrere Studentengenerationen ausführlich untersucht und so von nahezu allen Fehlern befreit. Auch erscheinen selbst aufwändige formale Methoden für Sicherheitsbeweise durchführbar. Konkrete Ergebnisse stehen allerdings noch aus.

Neben den Vorteilen von Microkernel-Systemen im Allgemeinen gibt es in Minix 3 eine ganze Reihe von Verbesserungen im Detail. So realisiert es Treiber als separate Prozesse im Usermode. Sie dürfen weder privilegierte Befehle oder I/O-Operationen durchführen noch direkt in den Speicher schreiben. Diese Operationen führen überprüfbare Kernelaufrufe durch (siehe Abbildung 1).

Abbildung 1: Der Microkernel von Minix kapselt viele Subsysteme im Userspace. Dazu gehören die Treiber, das Dateisystem und der Netzwerkstack. Im Kernel verbleiben nur die wichtigsten Funktionen, darunter I/O-Basisfunktionen, Scheduler und das Memory-Management.

Zur Prozesskommunikation verwendet Minix 3 Nachrichten fester Länge. Diese Designentscheidung vereinfacht die Codestruktur und hilft die Gefahren von Buffer-Überläufen zu verringern. Das Minix-Filesystem läuft als einfacher User-Prozess. Da es aus ungefähr 8200 Zeilen Quelltext im Userspace, aber keinem Code im Kernel besteht, lässt es sich gut debuggen. Fehler im Filesystem gefährden also nicht die Sicherheit des Kernels. Ähnliches gilt auch für Teile der Speicherverwaltung und den Netzwerkstack.

Minix erhöht die Zuverlässigkeit des Systems durch einen Reincarnation-Server. Der Prozess ist der Vater aller Server und Treiber. Er erkennt Abstürze schnell und überwacht kontinuierlich die Funktion kritischer Prozesse.

Wiederbelebte Server

Auf der “Free and Open Source Software Conference” (Froscon) an der Fachhochschule Bonn-Rhein-Sieg in Sankt Augustin berichtete Prof. Tanenbaum von Experimenten mit 200000 eingeschleusten Fehlern [9]. Zwar stürzten die Treiber über 18000-mal ab, der Reincarnation-Server startete sie aber jedes Mal neu: Während monolithische Systeme in solchen Fällen mit hoher Wahrscheinlichkeit abstürzen, lief Minix 3 stabil. Netzwerkverbindungen verlangsamten sich, brachen aber selbst nicht ab [10].

Viele Entwickler und Anwender belächeln die seit über einem Jahrzehnt durchgehaltene Doktrin von AndrewS.Tanenbaum, Erweiterungen höchst vorsichtig in den Kernel einzubauen. Die Vorgabe, ein sicheres Betriebssystem solle sich innerhalb einer einsemestrigen Vorlesung unterrichten lassen, ist sein Maß für eine vernünftige Komplexität eines Betriebssystems. Da Minix schon seit vielen Jahren Bestandteil vieler Lehrpläne ist, finden Uni-Projekte im Bereich eingebetteter Systeme leichter Programmierer mit guten Systemkenntnissen. Die Modularisierung macht es möglich, im Rahmen von Abschlussarbeiten praktisch einsetzbare Lösungenen vollständig zu entwickeln. Beispiele hierfür sind Portierungen für verschiedene Prozessorarchitekturen, die Anpassung von Minix an die Xen-Virtualisierung und die entwickelten Sicherheitsapplikationen.

Abbildung 2: Beim Start zeigt sich Minix übersichtlich. Die Version 3.1.2a bringt jedoch auch eine X11-Oberfläche und Entwickler-Werkzeuge mit.

Minix-Firewall-Projekt

Paketfilter sind gefährdete Systemkomponenten. Trotz der hohen Qualität der Netfilter-Implemention von Linux gab es in der Vergangenheit mehrfach Sicherheitsprobleme. Läuft ein solches Subsystem innerhalb des Linux-Kerns, gefährdet dies die Systemsicherheit. Anknüpfend an Arbeiten der Tanenbaum-Gruppe portierte die TFH Berlin das weitverbreitete Netfilter-Framework nach Minix 3 [11]. Dadurch verbesserte sie dessen Sicherheit und Stabilität erheblich.

Falls der Angreifer beispielsweise mit Hilfe eines Buffer Overflow in der Funktion »do_replace()« einen Absturz provoziert, zwingt dies eine Linux-Firewall mit hoher Wahrscheinlichkeit in die Knie. Innerhalb von Minix 3 implementiert, stürzt nur ein User-Prozess ab. Er kompromittiert nicht die Systemsicherheit und im günstigen Falle startet der Reincarnation-Server den Prozess neu.

Noch schwerer wiegen die Unterschiede, falls es dem Angreifer gelingt, Code auszuführen. Unter Linux ist die Gefahr groß, dass das gesamte System unter die Kontrolle des Angreifers fällt. Bei einer Minix-Firewall stellt ein übernommener Nutzerprozess ebenfalls ein Problem dar, jedoch sind die Auswirkungen durch die bessere Isolation weit geringer. Insbesondere verrichten überwachende Prozesse weiterhin ihre Arbeit.

Nach längerer Zeit haben sich die Vorzüge von Minix 3 auch bei Förderungsinstitutionen herumgesprochen, so unterstützt die EU das Projekt mit mehreren Millionen Euro, und Google hat mehrere Minix-Projekte in seinem Programm “Summer of Code”.

Einfach, frei und sicher

Da Minix 3 mit Xen und VMware zusammenarbeitet und mit 8 MByte nur sehr wenig Hauptspeicher-Ressourcen benötigt, erscheint es interessant, bestehende Serversysteme mit einer virtualisierten Minix-Firewall zu ergänzen. Dazu läuft eine Diplomarbeit an der Technischen Fachhochschule Berlin.

Das größte Hindernis für die Verbreitung von Minix war eine zwar preiswerte, aber unfreie Lizenz. Minix 3 ist unter der BSD Open Source Licencse veröffentlicht; die an der TFH Berlin entwickelten Erweiterungen der Firewall stehen unter der GPL.

Minix 3 hilft dabei, Betriebssysteme zu verstehen und zu entwickeln. Da das Microkernel-System diesmal von Anfang an unter einer Open-Source-Lizenz steht und einige überzeugende Sicherheitseigenschaften besitzt, erwarten seine Entwickler, dass seine Bedeutung insbesondere im Bereich von eingebetteten Systemen zunimmt. Es ist interessant, dass Microsoft mit Singulatity [12] ebenfalls mit nicht geringem Aufwand an einem Microkernel-System forscht. (mg)