Vistas Integrity Level, Teil 1

Inhaltsverzeichnis

Zugriffsschutz ist die Grundlage eines sicheren Betriebssystems: Nur wenn nicht jeder alles darf, kann man unerwünschte Aktivitäten von Schädlingen, etwa aus dem Internet, unterbinden. Mit der Benutzerkontensteuerung von Windows Vista versucht Microsoft, dem Anwender das Arbeiten mit eingeschränkten Rechten schmackhaft zu machen. Doch auch die Rechte eines normalen Benutzers gehen noch zu weit, wenn es einem Schädling gelingt, sich ihrer zu bemächtigen. Denn dann darf er im Namen des Benutzers zum Beispiel all dessen Dokumente ausspionieren, verändern oder löschen.

Programme, die das Ziel von Angriffen aus dem Internet sein könnten, sollte man also sicherheitshalber noch weiter einschränken. Im Prinzip bietet das Sicherheitsmodell von Windows XP dafür reichlich Möglichkeiten. Microsoft ist aber einen anderen Weg gegangen und hat Vista einen zusätzlichen Mechanismus spendiert, der dem bisherigen Sicherheitsmodell vorgeschaltet ist: die Mandatory Integrity Control.

Um die Gründe dafür und die Neuerungen zu verstehen, lohnt sich ein Blick auf das Sicherheitsmodell von Windows XP, das es so im Prinzip schon seit Windows NT gibt. Eine Vielzahl von Objekten im System steht unter seiner Kontrolle: Dateien, Registry-Schlüssel, Prozesse, Threads, Pipes und noch etliche mehr.

Akteure

Die handelnden Subjekte im System sind die Prozesse und Threads. Zu jedem Prozess gehört ein sogenanntes Access Token, das darüber bestimmt, was er alles tun darf. Zunächst einmal enthält es den Benutzer, in dessen Namen der Prozess handelt, in Form einer Security-ID (SID). SIDs sind Zahlen variabler Länge, die das System intern anstelle von Klartextnamen verwendet. Legt man ein neues Benutzerkonto an, so erhält es eine (aller Wahrscheinlichkeit nach) weltweit eindeutige SID, die auch dann erhalten bleibt, wenn man nachträglich den Benutzernamen ändert - wichtig, um Benutzer in einem Netzwerk auseinanderzuhalten.

Des Weiteren stecken im Access Token eine Liste von Gruppenzugehörigkeiten (auch als SIDs) und ein Satz von Privilegien. Privilegien sind Zugriffsrechte allgemeinerer Natur, die nicht an ein bestimmtes Objekt gebunden sind, wie etwa die Berechtigungen, den Rechner herunterzufahren oder Treiber zu laden.

Unter Vista zeigt der Kommandozeilenbefehl whoami /all einige der Informationen aus dem Access Token des Aufrufers an (streng genommen aus seinem eigenen). Für Windows XP stellt Microsoft das Programm als Bestandteil der kostenlosen Support Tools bereit (Download aller im Artikel erwähnter Software über den Soft-Link). Ein komfortableres Werkzeug, um Access Tokens und weitere im Folgenden erklärte Dinge unter die Lupe zu nehmen, ist der Process Explorer von Mark Russinovich. Er listet alle im System laufenden Prozesse und liefert nach Rechtsklick über den Menüpunkt Properties detaillierte Informationen. Die Daten aus dem Access Token finden sich auf der Registerkarte Security.

Requisiten

Die zweite für die Sicherheit wichtige Datenstruktur ist der Security Descriptor. Jedes der Zugriffskontrolle unterliegende Objekt im System hat einen Security Descriptor, der darüber bestimmt, wer was mit ihm tun darf. Seine wichtigsten Bestandteile sind die SID des Besitzers und eine Liste mit Zugriffsrechten, die Discretionary Access Control List (DACL). Die DACL besteht aus einer Reihe von Einträgen, die jeweils einer Security-ID bestimmte Rechte entweder zugestehen (Allow) oder entziehen (Deny).

Wenn ein Prozess auf ein Objekt zugreifen möchte, geht Windows die DACL im Security Descriptor des Objekts Eintrag für Eintrag durch und vergleicht die darin aufgeführten SIDs mit den im Access Token des Prozesses gespeicherten. Sobald es eine Deny-Regel für ein angefordertes Recht findet, die zu einer der SIDs im Access Token passt, lehnt Windows den Zugriff ab. Wenn nach dem Abarbeiten der ganzen Liste keine Allow-Regel für das gewünschte Recht gepasst hat, schlägt der Zugriff ebenfalls fehl. Diese vereinfachte Darstellung mag an dieser Stelle genügen, mehr Details in [1,2].

Allmächtiger Besitzer

Allmächtiger Besitzer

Das soeben geschilderte Sicherheitsmodell nennt sich auch Discretionary Access Control (DAC). Es heißt so, weil es im Ermessen (engl. discretion) des Besitzers eines Objekts liegt, Zugriffsrechte zu vergeben. Der Besitzer nimmt also eine Sonderrolle ein: Er darf jederzeit die DACL seiner Objekte verändern. Wenn die DACL eines seiner Objekte ihm den Zugriff verwehrt, kann er sich diesen in zwei Schritten verschaffen: Erst ändert er die DACL so, dass sie ihm Rechte einräumt, dann öffnet er das Objekt.

Administratoren müssen nötigenfalls einen Dreisprung machen: Sie führen das Privileg SeTakeOwnership in ihrem Access Token, das sie berechtigt, den Besitzer beliebiger Objekte zu ändern. Wenn also ein Administrator auf ein störrisches Objekt zugreifen will, muss er zunächst von ihm Besitz ergreifen, sich dann in der DACL ein Zugriffsrecht einräumen und kann es schließlich öffnen.

Durch diese Eigenschaften eignet sich die Discretionary Access Control nicht gut, um zur Vorbeugung gegen Sicherheitslücken gezielt die Rechte eines Prozesses wie des Internet Explorer einzuschränken. Natürlich könnte man dem IE eine spezielle SID in sein Access Token schreiben und minutiös DACLs setzen, die dieser SID allerlei verbieten. Doch solange der Prozess unter der User-ID des angemeldeten Benutzers läuft, lässt sich der Zugriff auf Objekte dieses Benutzers nicht verhindern.

Das mag einer der Gründe sein, warum sich Microsoft entschieden hat, in Vista einen zusätzlichen Sicherheitsmechanismus zu implementieren, der Vorrang vor der DAC hat, also Zugriffe auch dann verhindert, wenn sie die DAC erlauben würde. Dazu bekommt jeder Prozess in seinem Access Token einen sogenannten Integrity Level verpasst, der ausdrücken soll, wie vertrauenswürdig er ist. In Vista gibt es die vier Stufen Low, Medium, High und System: Auf der Stufe Medium laufen Programme mit normalen Benutzerrechten, High ist für administrative Tätigkeiten gedacht und die noch höhere Stufe System einigen Betriebssystemdiensten vorbehalten. Ganz unten, auf der Stufe Low, rangiert der Internet Explorer.

In der deutschen Vista-Version hat Microsoft Integrity Level unglücklich mit "Verbindlichkeitsstufe" übersetzt und aus den Labels, die gleich zur Sprache kommen, "Verbindliche Beschriftungen" gemacht. Da bleibe ich im Folgenden doch lieber bei den englischen Begriffen - wann immer Vista Ihnen etwas von "Verbindliche Beschriftung\Mittlere Verbindlichkeitsstufe" erzählt, denken Sie einfach Medium.

Von oben nach unten

Jedes Objekt im System befindet sich auf einer der vier genannten Stufen, gekennzeichnet durch ein Label in seinem Security Descriptor. Die Grundidee der Integrity Levels ist es nun, dass Prozesse, die auf einer niedrigeren Stufe laufen, Objekten höherer Stufe nichts anhaben können. So darf der Low-Level-IE die auf Medium stehenden Benutzerdaten nicht anrühren und schon gar nicht die noch höher eingestuften Systemkomponenten. Zugriffe von unten nach oben sind also beschränkt, während auf gleicher Ebene oder von oben nach unten alles erlaubt ist - im Rahmen der Discretionary Access Control, die ja auch noch ein Wörtchen mitzureden hat.

Das Label für den Integrity Level eines Objekts hat Microsoft in eine bisher nicht erwähnte Komponente des Security Descriptor gesteckt, die System Access Control List (SACL). Sie hat im Prinzip den gleichen Aufbau wie die DACL, ist also eine Liste von Einträgen, die aus einem Typ, einer SID und einer Handvoll Rechte-Bits bestehen. In XP dient die SACL nur dazu, bestimmte Zugriffsversuche auf ein Objekt zu protokollieren.

Vista führt einen neuen Eintragstyp für das Integrity Label ein sowie spezielle SIDs für die vier Stufen (durch die Dokumentation spukt auch noch eine fünfte namens Untrusted, die wir aber im Diesseits noch nicht gesichtet haben). In der SACL ist das Integrity Label gut aufgehoben, weil man besondere Privilegien braucht, um sie zu ändern. Insbesondere genügt es nicht, der Besitzer eines Objekts zu sein, um die SACL zu ändern.

Rechtlos

Rechtlos

Der SACL-Eintrag mit dem Integrity Label enthält drei Flags, die detailliert festlegen, welche Arten von Zugriff von unten nach oben unterbunden werden sollen: Schreiben (No Write Up), Lesen (No Read Up) oder Ausführen (No Execute Up). Im Dateisystem setzt Vista von sich aus immer "No Write Up" ein. Da für das Gros der Objekte die Stufe Medium vorgesehen ist, nimmt Vista diese als Standardwert an, wenn im Security Descriptor nichts explizit angegeben ist. Das führt unterm Strich dazu, dass der auf Low laufende Internet Explorer die meisten Dateien und Verzeichnisse nicht beschreiben darf, wohl aber lesen und Programme daraus ausführen kann.

Apropos Internet Explorer: Er taucht immer wieder als Beispiel auf, weil er das einzige Programm ist, das unter Vista standardmäßig auf dem Integrity Level Low läuft. Die Sicherheitsarchitektur des IE vollständig zu erklären würde den Rahmen dieses Artikels sprengen, daher hier nur so viel: Damit der Anwender auch mal eine heruntergeladene Datei in einem frei gewählten Verzeichnis abspeichern kann, hilft dem IE ein Broker-Prozess mit Integrity Level Medium, im Process Explorer zu finden unter dem Namen ieuser.exe. Wenn im Folgenden vom Internet Explorer die Rede ist, geht es immer um die mit Integrity Level Low laufende Hauptkomponente iexplore.exe, die es ja gegen potenzielle Sicherheitslücken abzusichern gilt.

Abtauchen

Vistas Eigenschaften-Dialoge für Dateien und Ordner wissen nichts von Integrity Levels, sodass man Kommandozeilenwerkzeuge bemühen muss, um sie sich anzusehen. Der Befehl icacls erlaubt das Anzeigen und Bearbeiten der DACL sowie des Integrity Level von Dateien und Verzeichnissen. Wenn Sie zum Beispiel in Ihrem User-Verzeichnis den Befehl

icacls AppData\LocalLow

eingeben, finden Sie in seiner Ausgabe die unsägliche "Verbindliche Beschriftung\Niedrige Verbindlichkeitsstufe", also das Label für den Integrity Level Low, gefolgt von "(OI)(CI)(NW)". NW steht für das oben erwähnte Zugriffs-Flag "No Write Up", OI und CI für die Vererbungs-Flags "Object Inherit" und "Container Inherit". Die Vererbungs-Flags legen fest, ob neu in einem Verzeichnis angelegte Objekte den betreffenden ACL-Eintrag erben. Windows unterscheidet dabei zwischen der Vererbung an einfache Objekte (Dateien) und Container-Objekte (Verzeichnisse). Die Ausgabe von icacls bedeutet also, dass das Verzeichnis LocalLow den Integrity Level Low hat und diesen an alle darin angelegten Dateien und Unterverzeichnisse vererbt. Microsoft hat es speziell als Speicherort für die Daten von auf niedriger Stufe laufenden Anwendungen vorgesehen.

Das Kommandozeilenprogrämmchen AccessChk von Mark Russinovich bietet etliche interessante Optionen, um Zugriffsrechte und Integrity Levels detaillierter zu erforschen. So listet beispielsweise der Befehl

accesschk -d -e -s c:\

alle Verzeichnisse auf, die explizit einen Integrity Level gesetzt haben. Auf diese Weise findet man neben AppData\LocalLow im User-Verzeichnis zahlreiche weitere Verzeichnisse im System, die den Integrity Level Low tragen und somit für den Internet Explorer beschreibbar sind, etwa den Ordner "Favorites" im User-Verzeichnis, diverse Ordner für temporäre Dateien, die History und so weiter.

Der zweite Teil des Artikels beantwortet die Frage, wie überhaupt Prozesse zu ihren Berechtigungen und damit zu ihrem Integrity Level kommen. Zudem zeigen wir in einem Praxisbeispiel, wie man Firefox dazu bekommt, mit dem Integrity Level Low zu laufen.

Tools zum Artikel

• Process Explorer im Software-Verzeichnis
  Sysinternals/Microsoft-Tool, das detaillierte Informationen zu allen Prozessen im System anzeigt.
  
• Windows XP Service Pack 2 Support Tools im Software-Verzeichnis
  Enthält unter anderem das im Artikel erwähnte Kommandozeilenprogramm whoami.exe
  
• AccessChk im Software-Verzeichnis
  Tool von Mark Russinovich zum Überprüfen von Zugriffsrechten, insbesondere zur Anzeige von Integrity Levels.
  
• chml von Mark Minasi im Software-Verzeichnis
  Ein Utility zum Umgang mit Integrity Levels.

Literatur

[1] Mark E. Russinovich, David A. Solomon, Microsoft Windows Internals, Fourth Edition, Microsoft Press 2005

[2] Karsten Violka, Du darfst, du nicht, Zugriffsrechte unter Windows gezielt vergeben, c't 13/06, S. 220 (bo)