Vistas Integrity Level, Teil 1

In Vista hat Microsoft das bisherige Sicherheitsmodell von Windows um Integrity Level erweitert. Damit sollen sich risikoreiche Programme vom System abschotten lassen. Die Grundlagen und Praxisbeispiele zeigt der Artikel.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 12 Min.
Von
  • Dr. Harald Bögeholz
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.

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.

Das Access Token eines Prozesses oder Threads legt fest, was dieser tun darf.

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.

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