Vistas Integrity Level, Teil 1
Seite 3: 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)