Gekapselt und überschaubar: Minix 3 strebt nach Sicherheit

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."