Die Sicherheit von Betriebssystemen

Ein Beitrag von Prof. Dr. Gunnar Teege, Institut für Technische Informatik, Universität der Bundeswehr München

Auch Handys, Consumer-Elektronik-Geräte und eingebettete Systeme sind heute Rechner mit einem Betriebssystem. Was kann das Betriebssystem zur Sicherheit beitragen, wo liegen typische Schwachstellen? Über den Selbstschutz von Betriebssystemen, den Schutz von Daten und Nutzen und wie sich diese Sicherheit bewerten lässt. Doch zu Anfang 

Bedeutung von Sicherheit

Welches Betriebssystem ist jetzt sicherer, Windows oder Linux? Diese Frage am Beginn der Vorlesung über Betriebssystemsicherheit führt schnell zur Diskussion, was es denn bedeutet, dass ein Betriebssystem sicher ist. Soll es die Hardware schützen, die Anwendungen oder den Nutzer? Soll es vor Angriffen aus dem Netz schützen, vor Datendieben, die sich physikalischen Zugang zum Rechner verschafft haben, oder vor Nutzern, die die Daten anderer Nutzer ausspähen wollen? Oder soll es sogar verhindern, dass sein Nutzer illegal Videos vervielfältigt?

Alte Zeiten

Vor 50 Jahren war das alles viel einfacher. Rechner hatten die Größe von Schränken, wurden weder herumgetragen noch verloren und waren für Privatpersonen unerschwinglich. Die Institutionen, die sich weltweit Sorgen um die IT-Sicherheit machten ließen sich an einer Hand abzählen, prominentester Vertreter war das US-Verteidigungsministerium. Hier entstanden die Wurzeln der Forschung über IT-Sicherheit im Allgemeinen und über sichere Betriebssysteme im Besonderen.

Der „use case“ war ähnlich wenig vielfältig: Zu ermöglichen, dass militärisch klassifizierte Dokumente („vertraulich“, „geheim“) auf Computern verarbeitet werden können. Dazu müssen die Nutzer unterschiedliche Berechtigungen haben und das Betriebssystem muss sie voneinander isolieren. Dabei sollte das Betriebssystem aber beispielsweise auch verhindern, dass ein Nutzer mit Zugriffsberechtigung auf ein Dokument dieses versehentlich oder absichtlich an Nutzer ohne diese Berechtigung weitergibt.

Anforderungen an Betriebssysteme

Veröffentlichungen aus dieser Zeit lesen sich sprachlich schon etwas antiquiert, inhaltlich aber hochaktuell. So wurde damals bereits erkannt, dass das Betriebssystem diese Aufgaben nur garantiert erfüllen kann, wenn es selbst vor Änderung seines Binärcodes und seiner Daten geschützt ist. Dies war eine von drei Anforderungen („tamper proof“) des „Referenzmonitor-Konzepts“, das eine Arbeitsgruppe unter James P. Anderson 1972 formulierte. Und zwischen der unberechtigten Weitergabe geheimer Dokumente und der illegalen Verbreitung digitalisierter Blockbuster besteht technisch kaum ein Unterschied.

Selbstschutz und Maßnahmen

Praktisch hatte der Selbstschutz des Betriebssystems wegen der stark eingeschränkten Zugänglichkeit allerdings keine hohe Priorität. Das ist heute durch Vernetzung und Mobilität anders: Ein Handy ist ständig von Milliarden anderer Computer aus erreichbar und kann leicht gestohlen oder in einem unbeaufsichtigten Moment manipuliert werden.

Typische Selbstschutzmaßnahmen sind Signierung oder verschlüsselte Speicherung des Betriebssystems und seiner Daten. Dies ermöglicht es beim Systemstart die Integrität durch den Boot-Lader zu verifizieren. Doch wer kontrolliert den Kontrolleur? Auch die Boot-Lader-Software kann manipuliert werden. Eine moderne UEFI Firmware, die „secure boot“ mit entsprechenden Maßnahmen realisiert, ist im Flash-ROM gespeichert und kann relativ leicht ersetzt werden (das ist auch notwendig, wenn mal wieder eine Schwachstelle erkannt und ein Update bereitgestellt wird).

Man „löst“ dieses Problem durch immer längere Ketten sich kontrollierender Kontrolleure. Bei heutigen Systemen reichen diese Ketten bis in die Hardware: der Mikrocode moderner Intel-Prozessoren mit der Technologie „Verified Boot“ hat die Fähigkeit, kryptografische Signaturen der Firmware zu prüfen (Abb. 1). Damit basiert die Integrität des Betriebssystems auf der (Prozessor-)Hardware. Da die Hardware auch alle Maschinenbefehle des Betriebssystems ausführt, muss ihre Integrität sowieso immer vorausgesetzt werden. Leider kann auch diese Voraussetzung heute problematisch sein.

Schutz für Nutzer und Daten

Die wichtigste Aufgabe des Betriebssystems in Bezug auf Sicherheit ist nach wie vor die Isolation verschiedener Nutzer oder Anwendungen voneinander, sowohl im Hauptspeicher als auch im Dateisystem. Gleichzeitig sollen aber auch kontrollierte Kanäle zum Informationsaustausch ermöglicht werden. Im Dateisystem geschieht dies durch die Verwaltung von Zugriffsrechten. Das Betriebssystem garantiert, dass nur ein Prozess mit den nötigen Rechten auf eine bestimmte Datei zugreifen kann.

Während das in den 1970er Jahren entstandene Rechtesystem von Unix, das auch heute in den meisten Linux-Systemen verwendet wird, noch relativ einfach war, sind seitdem hochkomplexe Rechtesysteme entstanden mit dem Ziel, Sicherheitsanforderungen immer besser erfüllen zu können. Insbesondere Rechte zur Rechtevergabe tragen zur Steigerung der Komplexität bei. Bereits die WindowsSysteme seit 2000 haben ein deutlich komplexeres Rechtesystem. Die von der NSA und RedHat entwickelte open-source Linux-Erweiterung SeLinux („Security enhanced Linux“) übertrifft dies noch bei weitem.

Probleme mit dem Rechtesystem

Diese Komplexität wird zum Problem. Schwachstellen bestehen heute nicht in einer fehlerhaften Rechteprüfung durch das Betriebssystem, sondern aus fehlerhaft vergebenen Zugriffsrechten. Als Lösung wird gerne die systembestimmte Zugriffskontrolle („mandatory access control“) propagiert. Dabei werden alle grundlegenden Rechte durch den (Sicherheits-)Administrator verwaltet. Das reduziert zwar den Personenkreis, der Fehler bei der Rechtevergabe machen kann, aber auch Administratoren sind nur Menschen.

Und das schönste Rechtesystem ist wirkungslos, wenn der Angreifer (oder Forensiker) die Festplatte ausbaut und auf einem Rechner ausliest, der die auf der Platte gespeicherten Rechte einfach ignoriert. Das ist der Grund, warum die Festplatteninhalte verschlüsselt sein sollten. Im Betrieb besitzt das Betriebssystem den Schlüssel und ver- bzw. entschlüsselt alle Daten beim Transport zwischen Hauptspeicher und Festplatte. Da es dies allerdings auch für einen Angreifer machen würde, ist die Verschlüsselung im Betrieb wiederum als einzelne Sicherheitsmaßnahme wirkungslos. Erst die Kombination aus Rechtesystem und Verschlüsselung ergibt einen hinreichenden Schutz der gespeicherten Daten (siehe Abb. 2). Dieses Beispiel ist typisch für Sicherheitseigenschaften: nicht die Stärke einzelner Mechanismen oder ihre Anzahl ist alleine entscheidend, sondern häufig erst ihre geeignete Kombination.

Sicherheitsbewertung

Auf der siebenstufigen Skala der Sicherheitszertifizierung von IT-Systemen gemäß „Common Criteria“ ist Windows 10 auf der untersten Ebene EAL1 zu finden. Standard-Betriebssysteme von PCs, Servern, Handys etc. erreichen maximal die Ebene EAL4 (u.a. Windows-Server-Varianten, Enterprise-Linux-Versionen und Windows Mobile). Das einzige komplett auf EAL5 zertifizierte Betriebssystem ist das Spezialsystem PR/SM von IBM, kein Betriebssystem erreicht eine höhere Stufe. Und selbst Stufe EAL7 garantiert noch nicht, dass das System keine Schwachstellen enthält.

Ein sicheres Betriebssystem

Die Forschung ist hier etwas weiter. 2013 wurden für das Mikrokern-Betriebssystem seL4 alle wesentlichen Sicherheitseigenschaften formal bewiesen. Der Aufwand dafür betrug allerdings das 15-fache des reinen Entwicklungsaufwands. Die Funktionalität des 10.000 Code-Zeilen umfassenden seL4 ist zwar grundlegend, aber rudimentär. Bis vergleichbare Sicherheit für ein Standard-Betriebssystem mit vielen Millionen Code-Zeilen erreichbar ist, dürften noch einige Jahre vergehen. Die Frage ist also nicht, ob Windows oder Linux, sondern wie und wann überhaupt hinreichend sichere Betriebssysteme praktisch einsetzbar sind und wie diese aussehen werden.