Sicherheit

Neue ACLs erhöhen die Sicherheit in Windows Vista

Jesper Johansson

 

Kurz zusammengefasst:

  • Neuerungen bei ACLs
  • Strengere Kontrollen für Administratoren
  • Berechtigungen für vertrauenswürdige Installationsprogramme
  • Geänderte Benutzer und Gruppen

Die grundlegende Struktur von Zugriffskontrolllisten (Access Control Lists, ACLs) hat sich in Bezug auf Windows Vista nicht wesentlich geändert, aber es gibt einige geringfügige und dennoch wichtige Änderungen, die Sie kennen müssen. Einige Änderungen

waren notwendig, weil ACLs in Windows® XP bei verschiedenen Problemen eine Rolle spielen. Erstens werden die meisten Windows XP-Benutzer als Administrator ausgeführt. Das heißt, sie verwenden ein Konto, das Mitglied der integrierten Gruppe „ADMINISTRATOREN“ ist. Bei privaten Benutzern ist dies praktisch immer der Fall, da alle Konten, die bei der Installation hinzugefügt werden, als Administratoren eingerichtet werden. Daher werden alle Programme, die diese Benutzer starten, ebenfalls mit Administratorrechten ausgeführt, die ihnen uneingeschränkten Zugriff auf das Betriebssystem geben. Dies ist natürlich besonders problematisch, wenn es sich bei diesen Programmen um böswillige Programme handelt.

Das zweite Problem, das in Angriff genommen werden musste, bestand darin, dass die Standard-ACLs in früheren Versionen von Windows viele Benutzer nervös gemacht haben, weil sie ACL-Einträge (ACEs) für „ALLE“, „HAUPTBENUTZER“ und so weiter enthielten. So erteilte beispielsweise die Standard-ACL im Stammverzeichnis des Startvolumes (normalerweise C:\) in Windows XP Mitgliedern der Gruppe „ALLE“ Lesezugriff und die Berechtigung, Ordner für Mitglieder der Gruppe „BENUTZER“ zu erstellen. Außerdem gab es in Windows XP Einschränkungen dafür, was Sie mit ACLs ausführen konnten. So gab es in Windows XP beispielsweise keine Möglichkeit, dem aktuellen Besitzer eines Objekts Berechtigungen zuzuweisen. Dem Besitzer konnten zwar Berechtigungen erteilt werden, aber wenn sich der Besitzer änderte, wurden diese Berechtigungen nicht übertragen. In ähnlicher Weise verfügten Besitzer unabhängig davon, welche Berechtigungen ihnen für ein Objekt zugewiesen wurden, immer über implizite Rechte für dieses Objekt.

Mit Windows Vista™ hat Microsoft das Projekt in die Wege geleitet, viele dieser Probleme zu beheben und Unterstützung für weitere Funktionen wie die Benutzerkontensteuerung (User Account Control, UAC) bereitzustellen. Dieser Artikel konzentriert sich auf die wichtigsten Änderungen, die in Windows Vista in Bezug auf die Zugriffssteuerung vorgenommen wurden. Im nächsten Monat geht es dann um die Tools, mit denen die Zugriffssteuerung verwaltet werden kann.

Neue und geänderte Benutzer und Gruppen

Einige Benutzer und Gruppen in Windows Vista sind neu, und einige ältere Funktionen aus Windows XP wurden entfernt. Darüber hinaus wurde bei einigen die Funktionsweise geändert. Jede dieser Änderungen hat Auswirkungen auf die Verwaltung der Zugriffssteuerung.

Administrator – Standardmäßig deaktiviert Das integrierte ADMINISTRATOR-Konto mit der relativen ID (RID) 500 ist jetzt in den meisten Fällen standardmäßig deaktiviert. ADMINISTRATOR war als Notfallkonto vorgesehen, das zur Wiederherstellung des Computers verwendet werden sollte, wenn alle anderen Methoden fehlschlugen. In den meisten Fällen wurde es jedoch als Standardkonto für die Administration verwendet, was einen Verstoß gegen mehrere Sicherheitsprinzipien darstellte. Der Verstoß gegen das wichtigste dieser Prinzipien, das Prinzip der Verantwortlichkeit, hatte zur Folge, dass es nicht mehr möglich war nachzuverfolgen, wer Änderungen am System vornahm. Daher ist dieses Konto jetzt teilweise veraltet. Microsoft wird dieses Konto wahrscheinlich irgendwann völlig abschaffen, aber vorläufig ist es standardmäßig deaktiviert. Wenn Sie keine anderen lokalen Konten in der Gruppe „ADMINISTRATOREN“ besitzen, kann RID 500 weiterhin in der Wiederherstellungskonsole und im abgesicherten Modus verwendet werden, wenn dies aber nicht der Fall ist, kann und sollte es nicht verwendet werden.

Beachten Sie, dass zwischen dem integrierten ADMINISTRATOR-Konto und anderen Konten der Gruppe „ADMINISTRATOREN“ ein Unterschied besteht. Wir schreiben „ADMINISTRATOR“ in der Regel groß, wenn wir uns auf das Konto mit der RID 500 beziehen, um es von einem „Administrator“ abzuheben, der ein anderes Konto der integrierten Gruppe „ADMINISTRATOREN“ verwendet. Gruppennamen werden ebenfalls groß geschrieben.

In Windows XP verfügte das integrierte ADMINISTRATOR-Konto über mehrere spezielle Rechte und Berechtigungen, die kein anderer Administrator besaß. Viele dieser Rechte und Berechtigungen wurden in Windows Vista entfernt, aber es gibt zwei wichtige Ausnahmen: Erstens kann ein deaktiviertes ADMINISTRATOR-Konto in der Wiederherstellungskonsole verwendet werden, wenn es keine anderen lokalen Administratoren gibt. Zweitens unterliegt der ADMINISTRATOR nicht der Benutzerkontensteuerung (User Account Control, UAC), und er verfügt immer über ein vollständiges Administratortoken. Dasselbe gilt für den DOMÄNENADMINISTRATOR (RID 500 in einer Domäne).

HAUPTBENUTZER-Berechtigungen wurden entfernt Die alte HAUPTBENUTZER-Gruppe wurde aus praktischen Gründen abgeschafft. Die Gruppe ist zwar noch vorhanden, aber die meisten Berechtigungen, die sie früher hatte, wurden entfernt. Es war kein Geheimnis, dass ein Benutzer, der Mitglied der HAUPTBENUTZER-Gruppe war, im Grunde ein Administrator war, der sich lediglich noch nicht selbst zum Administrator gemacht hatte. Ich habe einmal einen Computer, auf dem alle Patches installiert waren und Windows XP Service Pack 2 (SP2) ausgeführt wurde, in weniger als 45 Minuten übernommen, indem ich mir selbst Administratorberechtigungen zuwies. In dieser Zeitspanne habe ich den Computer erkundet, ein kleines Programm in C++ geschrieben und mich ab- und wieder angemeldet, um die Übernahme abzuschließen, was möglich war, weil ich ein Mitglied der Gruppe „HAUPTBENUTZER“ war.

Da viele Organisationen der Gruppe „HAUPTBENUTZER“ gut durchdachte Berechtigungen zugewiesen haben und sich darauf verlassen, dass ihre Benutzer dieser Gruppe angehören, konnte diese Gruppe in Windows Vista nicht einfach abgeschafft werden. Es ist jedoch wahrscheinlich, dass Microsoft in einer zukünftigen Version die Gruppe „HAUPTBENUTZER“ vollständig entfernen wird. Sie sollten deshalb langsam Pläne dafür entwerfen, die Verwendung der Gruppe „HAUPTBENUTZER“ aufzugeben.

Vertrauenswürdiges Installationsprogramm Das vertrauenswürdige Installationsprogramm ist eigentlich kein Benutzer, sondern ein Dienst, obwohl Sie im gesamten Dateisystem Berechtigungen sehen können, die ihm zugewiesen sind. Diensthärtung ermöglicht, dass jeder Dienst als vollwertiger Sicherheitsprinzipal behandelt wird, dem wie jedem anderen Benutzer Berechtigungen zugewiesen werden können. Einen Überblick über diese Funktion finden Sie im TechNet Magazin in der Ausgabe vom Januar 2007. Im Buch Windows Vista Security (Grimes und Johansson, Wiley Press, 2007) wird die Diensthärtung einschließlich ihrer Nutzung durch andere Funktionen wie die Firewall und IPSec ausführlich behandelt.

Dienst-SIDs werden nicht von den bisher bekannten Autoritäten wie NT AUTHORITY oder einer Domäne zugewiesen. Der vollständige Name des virtuellen Kontos „TrustedInstaller“ lautet „NT SERVICE\TrustedInstaller“, und es besitzt folgende SID:

S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

Sie können die SID jedes Diensts, sogar die SID von Diensten, die nicht existieren, anzeigen, indem Sie, wie in Abbildung 1 gezeigt, den Befehl „sc showsid“ ausführen.

Abbildung 1 „sc showsid“ zeigt die SID jedes Diensts, einschließlich der Dienste, die noch nicht existieren.

Abbildung 1** „sc showsid“ zeigt die SID jedes Diensts, einschließlich der Dienste, die noch nicht existieren. **(Klicken Sie zum Vergrößern auf das Bild)

Diese SID beginnt mit S-1-5-80. Beachten Sie hierbei, dass die erste Subautorität 80 ist, was für SECURITY_SERVICE_ID_BASE_RID steht und bedeutet, dass diese SID einem Dienst durch die Subautorität NT SERVICE erteilt wird. Dasselbe gilt für jeden anderen Dienst. Den übrigen Subautoritäten und den RIDs wird der Dienstname selbst zugrunde gelegt. Dies ermöglicht einem Entwickler, seinem Dienst Berechtigungen zu gewähren, ohne den Dienst zuerst erstellen und installieren zu müssen, da der Name deterministisch ist und sich von Computer zu Computer nicht unterscheidet.

Falls Sie den TrustedInstaller-Dienst im Dienstmanager nicht finden können: Sein Anzeigename lautet „Windows Modules Installer“.

Hilfs- und Supportkonten wurden entfernt Die Konten „Support_xxxxxx“ und „HelpAssistant“ wurden bei reinen Windows Vista-Installationen entfernt, sind jedoch weiterhin vorhanden, wenn die Installation durch Aktualisierung einer vorherigen Windows-Version erfolgt ist. Das Konto „Support_xxxxxx“ hatte dazu gedient, Skripts vom Supportcenter auszuführen. Einige OEMs, die eigene Hilfsinhalte bereitstellten, haben u. U. auch eigene Unterstützungskonten bereitgestellt. Es ist noch nicht klar, was mit OEM-Konten geschehen wird, aber höchstwahrscheinlich werden die OEMs einfach aufhören, sie zu erstellen. Genau genommen sind sie nicht mehr notwendig. Aus der Perspektive der Sicherheit betrachtet war es sowieso keine sehr gute Idee, Benutzern die Möglichkeit zu geben, Skripts vom Hilfecenter als ein anderer Benutzer auszuführen, und daher wäre es am besten, wenn diese Konten verschwinden würden. Windows Vista verfügt über einen neuen Mechanismus, um diese Aufgabe zu bewältigen.

Das HelpAssistant-Konto wurde während der Fernunterstützung verwendet. Wie beim Hilfecenter wurde auch die Fernunterstützungsfunktion neu konstruiert, um das HelpAssistant-Konto überflüssig zu machen, und daher wurde dieses Konto entfernt.

Neue Netzwerkspeicherort-SIDs Auf Windows NT® basierende Betriebssysteme besaßen schon immer einige auf Netzwerkspeicherorten basierende SIDs, z. B. NETWORK und INTERACTIVE, um Benutzer zu kennzeichnen, die sich über das Netzwerk und interaktiv anmelden. Es gibt auch eine REMOTE INTERACTIVE LOGON-SID, die Benutzern zugewiesen wird, die sich über Terminaldienste anmelden. (Beachten Sie, dass die Benutzer von Terminaldiensten in ihren Tokens sowohl REMOTE INTERACTIVE LOGON als auch INTERACTIVE LOGON besitzen.) In Windows Vista wurden zwei weitere SIDs hinzugefügt: DIALUP und INTERNET. Der genaue Grund für ein Konto, das eine Anmeldung über eine DFÜ-Verbindung kennzeichnet, ist ein wenig unklar, insbesondere, da immer mehr Benutzer nicht mehr online gehen, wenn eine Telefonleitung die einzige verfügbare Netzwerkverbindung ist, aber jetzt ist dieses Konto eben da. INTERNET soll offensichtlich jeden Benutzer kennzeichnen, der sich von einem Standort außerhalb des LANs anmeldet. NETWORK dagegen kennzeichnet jede Netzwerkanmeldung, einschließlich Benutzeranmeldungen aus dem Internet.

OWNER RIGHTS und Besitzerrechte Es gibt jetzt eine SID namens OWNER RIGHTS für Besitzerrechte, die für jeden Besitzer einer Datei gilt, sobald auf diese Datei zugegriffen wird. Sie dient in erster Linie zur Einschränkung der Funktionen, die der Besitzer mit der Datei ausführen kann. Im Vergleich zu Windows XP wurden zwei bedeutende Änderungen an den Besitzerrechten vorgenommen. Erstens haben dann, wenn Sie der Besitzer des Objekts sind, es für das Objekt aber einen für Sie geltenden Eintrag für die Zugriffssteuerung (Access Control Entry, ACE) gibt, die Rechte in der Zugriffssteuerung Vorrang vor der Tatsache, dass Sie der Besitzer sind. Dies ist eine wichtige Änderung, die sich gravierend auf bestimmte Aspekte der Systemverwaltung auswirkt, da wir daran gewöhnt sind, dass der Besitzer implizite Rechte besitzt. Zweitens kann die OWNER RIGHTS-SID dazu verwendet werden, stärker einzuschränken, welche Funktionen der Benutzer mit einem Objekt ausführen kann.

Nehmen wir beispielsweise einmal an, dass es einen Ordner gibt, für den die in Abbildung 2 gezeigte ACL gilt und dessen Besitzer der Benutzer Jesper ist. Obwohl der Benutzer Jesper der Besitzer dieses Ordners ist, verfügt er für den Ordner nur über Leseberechtigung. Wenn er versucht, eine Datei in den Ordner zu kopieren, schlägt dieser Versuch fehl, da er nicht die Berechtigung besitzt, in den Ordner zu schreiben. Dies ist jedoch aus den Fehlermeldungen nicht ganz klar zu ersehen. Wenn Sie versuchen, eine Datei in einen Ordner zu kopieren, dessen Besitzer Sie sind, aber nicht über Schreibberechtigungen zum Verwenden von Windows Explorer® verfügen, geschieht Folgendes: Zunächst teilt Explorer Ihnen mit, dass Sie Ihre Berechtigungen erweitern müssen, um diese Datei zu kopieren, aber in Wirklichkeit schlägt das Kopieren der Datei fehl, da Sie nicht das Recht besitzen, etwas in diesen Ordner zu kopieren. Sie erhalten die Fehlermeldung „Sie benötigen Berechtigungen zur Durchführung des Vorgangs.“, und es werden die beiden Schaltflächen „Wiederholen“ (als ob das helfen würde) und „Abbrechen“ angezeigt. Dies geschieht, obwohl Sie der Besitzer sind.

Abbildung 2 Nur „Lokales System“ und ein weiterer Benutzer haben Zugriff auf diesen Ordner.

Abbildung 2** Nur „Lokales System“ und ein weiterer Benutzer haben Zugriff auf diesen Ordner. **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Jesper versucht, die ACL für die Datei zu ändern, wird er aufgefordert, dazu sein Token zu erweitern. Da er der Besitzer der Datei ist, kann er dies tun. Der Besitzer besitzt weiterhin implizite Rechte zum Lesen und Ändern der ACL (READ_CONTROL und WRITE_DAC), sofern es keinen ACE für OWNER RIGHTS gibt, der etwas anderes besagt.

Um die Wirkung der OWNER RIGHTS-SID verständlicher zu machen, fügen wir dies jetzt der oben gezeigten ACL hinzu. Jetzt gelten die in Abbildung 3 gezeigten Berechtigungen.

Abbildung 3 Durch das Hinzufügen von OWNER RIGHTS-Berechtigungen zum Ordner werden Jespers Berechtigungen geändert.

Abbildung 3** Durch das Hinzufügen von OWNER RIGHTS-Berechtigungen zum Ordner werden Jespers Berechtigungen geändert. **(Klicken Sie zum Vergrößern auf das Bild)

Wenn mit diesen Berechtigungen jetzt versucht wird, über das Jesper-Konto etwas in den Ordner zu kopieren, gelingt dies sofort, da Jesper der Besitzer ist und er die entsprechenden Rechte besitzt. Wenn Jesper jedoch versucht, die ACL für das Objekt zu ändern, schlägt dieser Versuch fehl! Der ACE für OWNER RIGHTS gibt an, dass der Besitzer nur die Änderungsberechtigung, aber nicht die Fähigkeit besitzen soll, die freigegebene Zugriffssteuerungsliste (Discretionary Access Control List, DACL) zu ändern. Daher werden OWNER RIGHTS-Berechtigungen in erster Linie dazu verwendet, dem Besitzer WRITE_DAC (die Fähigkeit, den Sicherheitsdeskriptor zu ändern) zu nehmen.

Wenn ein Administrator den Besitzer des Objekts ändert, werden die OWNER RIGHTS-Berechtigungen nicht automatisch auf den neuen Besitzer übertragen. In diesem Fall wird der OWNER RIGHTS-ACE deaktiviert, indem er als IO (Inherit-Only, nur vererben)-ACE gekennzeichnet wird, aber weder auf Container noch auf Objekte angewendet wird, wodurch er also eigentlich auf gar nichts angewendet wird. Durch diese Aktion wird sichergestellt, dass Administratoren nicht vollständig vom Objekt ausgesperrt werden. Um den OWNER RIGHTS-ACE wieder zu aktivieren, muss der ADMINISTRATOR den ACE manuell aktivieren. Um dies zu tun, kennzeichnen Sie ihn je nach Bedarf dafür, auf diesen Ordner, auf Unterordner und auf Dateien angewendet zu werden.

Es gibt mehrere interessante Szenarios, in denen die OWNER RIGHTS-SID nützlich sein kann, z. B. dann, wenn der Administrator Benutzern die Möglichkeit erteilen will, auf einem Dateiserver Dateien und Ordner zu erstellen, er aber zugleich verhindern will, dass sie ACLs für diese Ordner ändern können. Eine andere denkbare Situation liegt vor, wenn Benutzer zu einem bestimmten Zeitpunkt Mitglieder einer Gruppe sind und möglicherweise aus betrieblichen Gründen einige Objekte erstellen, aber später aus dieser Gruppe entfernt werden. Zu diesem Zeitpunkt dürften sie nicht mehr in der Lage sein, die Einstellungen für diese Objekte zu ändern.

OWNER RIGHTS werden bei der Diensthärtung in hohem Maße eingesetzt. Wenn ein Dienst zur Laufzeit ein temporäres Objekt erstellt, ist der Ersteller des Objekts die primäre SID des Dienstprozesses (in der Regel LocalSystem, NetworkService oder LocalService) und nicht die SID für den Dienst selbst. Dies bedeutet, dass jeder andere Dienst, der im gleichen Prozesskontext ausgeführt wird, das Objekt ändern kann, was mit fast absoluter Sicherheit nicht wünschenswert ist. Durch Festlegen einer OWNER RIGHTS-SID für derartige Objekte kann das Betriebssystem verhindern, dass andere Dienste auf sie zugreifen.

Standard-ACLs

Die Standard-ACLs von Windows XP waren eigentlich recht gut. Abgesehen von einigen kleineren Problemen (z. B., dass sie den Benutzern erlaubten, Dateien im Stammverzeichnis des Startvolumes abzulegen) arbeiteten sie sehr vernünftig. Einige OEMs haben jedoch offenbar entschieden, dass sie besser wissen, wie Sicherheit vernünftigerweise auszusehen hat. Der Bildschirm in Abbildung 4 zeigt die ACL für das Windows-Verzeichnis eines Computers, auf dem von einem wichtigen OEM Windows XP Media Center Edition ausgeführt wird. Der OEM hat die Dateisystemsicherheit praktisch völlig deaktiviert.

Abbildung 4 Eine vom OEM konfigurierte ACL.

Abbildung 4** Eine vom OEM konfigurierte ACL. **

Microsoft hat in Windows Vista einige Anpassungen an ACLs vorgenommen. Wenn Sie an Windows XP gewöhnt sind, wissen Sie, dass die ADMINISTRATOREN-Gruppe der Besitzer aller Betriebssystemdateien ist und dass die Administratoren die volle Kontrolle über diese Dateien haben. Als Mitglied dieser Gruppe hatten Sie folglich uneingeschränkten Zugriff auf diese Dateien. Dies ist in Windows Vista nicht der Fall.

Vertrauenswürdiges Installationsprogramm In Windows Vista ist der Besitzer der meisten Betriebssystemdateien die TrustedInstaller-SID, und nur diese SID verfügt über vollständige Kontrolle über diese Dateien. Dies ist Teil der Systemintegritätsmaßnahmen, die in Windows Vista eingeflossen sind, und dient speziell dazu, zu verhindern, dass die Dateien von einem als Administrator oder als „Lokales System“ ausgeführten Prozess automatisch ersetzt werden. Um eine Betriebssystemdatei zu löschen, müssen Sie daher Besitzer der betreffenden Datei werden und danach einen ACE für die Datei hinzufügen, der es Ihnen erlaubt, die Datei zu löschen. Dies bietet eine dünne Schutzschicht gegen einen Prozess, der als „Lokales System“ ausgeführt wird und ein Systemintegritätslabel besitzt. Ein Prozess mit einer niedrigeren Integrität soll nicht in der Lage sein, seine Integrität selbst zu erweitern, um die Besitzrechte ändern zu können. Einige Dienste können beispielsweise mit mittlerer Integrität ausgeführt werden, obwohl sie als „Lokales System“ ausgeführt werden. Da solche Dienste keine Systemdateien ersetzen können, kann es nicht passieren, dass durch Ausnutzung eines solchen Diensts Betriebssystemdateien ersetzt werden, wodurch es etwas schwerer wird, auf dem System ein Rootkit oder andere böswillige Programme zu installieren. Dies erschwert es auch für Systemadministratoren, die sich durch die Anwesenheit einer Systembinärdatei gestört fühlen, diese Binärdatei zu entfernen.

Verweigern-ACEs Sie werden feststellen, dass viele Objekte im Dateisystem Verweigern-ACEs für die Gruppe „ALLE“ besitzen, was unter Administratoren viel Unruhe ausgelöst hat. Wenn Sie die Option „Versteckte Dateien anzeigen“ aktivieren, sehen Sie das vertraute Verzeichnis „Dokumente und Einstellungen“. Wenn Sie darauf klicken, wird jedoch die Fehlermeldung „Zugriff verweigert“ ausgegeben. Damit Sie verstehen, was es mit „Dokumente und Einstellungen“ auf sich hat, sehen Sie sich die Verzeichnisliste in Abbildung 5 an.

Abbildung 5 „Dokumente und Einstellungen“ ist kein Verzeichnis, sondern ein Verknüpfungspunkt.

Abbildung 5** „Dokumente und Einstellungen“ ist kein Verzeichnis, sondern ein Verknüpfungspunkt. **(Klicken Sie zum Vergrößern auf das Bild)

„Dokumente und Einstellungen“ ist in Wirklichkeit gar kein Verzeichnis, sondern ein Verknüpfungspunkt! Denken Sie daran, dass Verknüpfungspunkte symbolischen Links ähneln, die ganz einfach zur Umleitung des Zugriffs dienen. In diesem Fall wird zu einem Verzeichnis namens „C:\Benutzer“ umgeleitet. Microsoft hat den Dateisystemnamespace in Windows Vista beträchtlich geändert und die Benutzerdaten in das Verzeichnis „C:\Benutzer“ verschoben. Andere Elemente unter dem früheren Namespace „C:\Dokumente und Einstellungen\<Benutzername>“ wurden ebenfalls verschoben. So wurde beispielsweise „C:\Dokumente und Einstellungen\<Benutzername>\Anwendungsdaten“ in das Verzeichnis „C:\Benutzer\<Benutzername>\appdata\roaming“ verschoben. Sie können diese Änderungen ganz deutlich erkennen, wenn Sie zu einer Befehlszeile wechseln und den Befehl „dir /a“ eingeben, wie das in Abbildung 5 erfolgt ist. Der Grund, aus dem der Namespace so drastisch geändert wurde, besteht darin, ihn für Benutzer verständlicher zu machen und Dokumente und Daten sauberer voneinander zu trennen. Statt alle Dateien unter dem Ordner „Eigene Dateien“ zu speichern, können Entwickler jetzt unter dem Profil des Benutzers ihre eigenen Ordner anlegen, die der Benutzer dort sehen kann. Anwendungsdaten für alle Benutzer kommen jetzt in einen ausgeblendeten Ordner namens „%systemroot%\ProgramData“, statt unter „Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten“ abgelegt zu werden.

Microsoft hat den Namespace „C:\Dokumente und Einstellungen“ nicht entfernt, weil in älteren Anwendungen möglicherweise dieser Name anstelle der bevorzugten Umgebungsvariablen wie %USERPROFILE% im Code verwendet wird. Diese Anwendungen würden blockieren, wenn „C:\Dokumente und Einstellungen“ nicht mehr vorhanden wäre. Stattdessen wird dieses Verzeichnis jetzt durch Verknüpfungspunkte oder so genannte „symlinks“ vertreten, um die Abwärtskompatibilität sicherzustellen. Anwendungen, in denen diese Pfade fest kodiert sind, können abhängig davon, wie sie auf die darin enthaltenen Daten zugreifen, weiterhin blockieren, aber diese Anwendungen blockieren bereits in Windows-Versionen anderer Sprachen als Englisch. Und dies ist ein wirklich wichtiger Punkt. Wenn eine Aktualisierung für Windows, z. B. Windows XP SP2 oder Windows Vista, dazu führt, dass Drittanbieterprogramme blockieren, liegt es fast immer daran, dass die Entwickler dieser Programme unzulässige Annahmen vorausgesetzt oder Windows auf eine unzulässige Weise verwendet haben.

Wenn Sie beispielsweise versuchen, eine Datei zu öffnen, indem Sie „C:\Dokumente und Einstellungen\<Benutzername>\Eigene Dateien\foo.txt“ eingeben, dann funktioniert dies, vorausgesetzt, dass sich an diesem Speicherort eine Datei namens „foo.txt“ befindet. Wenn Sie jedoch versuchen, zu „C:\Dokumente und Einstellungen\<Benutzername>\Eigene Dateien“ zu navigieren, erhalten Sie die Fehlermeldung „Zugriff verweigert“. Sehen Sie sich zur Klarstellung die ACL in Abbildung 6 an.

Abbildung 6 Es existiert ein Verweigern-ACE für „Dokumente und Einstellungen“.

Abbildung 6** Es existiert ein Verweigern-ACE für „Dokumente und Einstellungen“. **(Klicken Sie zum Vergrößern auf das Bild)

Betrachten Sie den ersten ACE in der Liste. Es handelt sich um einen Verweigern-ACE für die Gruppe „ALLE“ zum Auflisten der Ordnerinhalte. Programme können die Verknüpfungspunkte und offenen Dokumente mit absoluten Pfaden durchlaufen, weil die Gruppe „ALLE“ über die Berechtigung zum Umgehen der Traversierungsüberprüfung (auch unter dem Namen „SeChangeNotifyPrivilege“ bekannt) verfügt. Die Versuche eines Benutzers oder eines Prozesses, die von ihnen repräsentierten Verzeichnisse aufzuzählen, schlagen aufgrund des Verweigern-ACEs fehl. Aus diesem Grund kann der Benutzer weder tatsächlich sehen, was in „C:\Dokumente und Einstellungen“ enthalten ist, noch dieses „Verzeichnis“ löschen. Dieser Verweigern-ACE soll Benutzer in erster Linie daran hindern, die Verknüpfung zu löschen und ältere Anwendungen zu blockieren. Darüber hinaus soll er Entwickler daran erinnern, keine Anwendungen zu programmieren, die den alten Namespace verwenden, sondern stattdessen Umgebungsvariablen oder Registrierungszeichenfolgen zu verwenden, um eine Anwendung vor zukünftigen Änderungen und Sprachunterschieden zu isolieren.

Beachten Sie, dass alle diese Verknüpfungspunkte standardmäßig ausgeblendet sind und von den meisten Benutzern nie gesehen werden. Um ein Löschen der sichtbaren Verknüpfungspunkte zu verhindern, hat Microsoft einen Verweigern-ACE für „Ordner auflisten“ eingefügt.

Traversierungsüberprüfung umgehen Der Grund, weshalb Benutzer auf Dateien, für die sie Rechte haben, innerhalb von Ordnern (oder Verknüpfungspunkten) zugreifen können, für die sie keine Rechte haben, liegt darin, dass jeder über die Berechtigung „Traversierungsüberprüfung umgehen“ verfügt. Die Berechtigung „Traversierungsüberprüfung umgehen“ (oder SeChangeNotifyPrivilege) ist die grundlegendste Berechtigung in Windows und wird einem Prozess gewährt, bei dem alle anderen Berechtigungen entfernt wurden, es sei denn, der Prozess verlangt ausdrücklich, dass diese Berechtigung ebenfalls entfernt wird. Dies geschieht, wenn ein Prozess in Windows Vista mithilfe der Zeile „runas /trustlevel:0x10000“ < gestartet wird. Das durch <command> angegebene Programm wird mit einem beschränkten Token ausgeführt und alle Berechtigungen außer SeChangeNotifyPrivilege werden aus dem Prozesstoken entfernt.

Interessanterweise erhalten Sie durch trustlevel 0x20000 ein Token mit dem normalen Satz von SIDs, aber ohne Berechtigungen. Mit 0x40000 erhalten Sie ein völlig normales Token.

Standardberechtigungen

Die Standardberechtigungen für das Dateisystem haben sich in Windows Vista im Vergleich zu Windows XP geringfügig geändert. Wenn Sie die ACL für „%systemdrive%“ (normalerweise das Startvolume C:) in Windows XP oder Windows Server® 2003 betrachten, sehen Sie Folgendes (oder bei sehr frühen Versionen von Windows XP etwas sehr Ähnliches):

D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU) 

Hier ist dieselbe ACL für dasselbe Verzeichnis in Windows Vista:

D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU) 

Es gibt eine Reihe wichtiger Unterschiede. Zunächst gibt es statt nur einem ACE jetzt zwei ACEs für BA (BUILTIN\Administrators). Das Endergebnis ist jedoch dasselbe. Ein ACE wird in Windows Vista nicht geerbt und gewährt vollen Zugriff auf das Stammverzeichnis und ein ACE ist ein IO (Inherit-Only, nur vererben)-ACE, der von Containern und Objekten geerbt wird und GA (Generic All, volle Kontrolle) gewährt. Dasselbe gilt für die Ersetzung des einzelnen ACEs für SY (LocalSystem) durch zwei ACEs in Windows Vista. In Windows XP hat der einzelne ACE vollen Zugriff gewährt und wurde von Objekten und Containern geerbt. Auch hier ist das Endergebnis dasselbe. Der Hauptgrund für die Änderung der ACL besteht darin, dass die Berechtigungen verdeutlicht und abgetrennt werden sollen, damit die ACL leichter verwaltet und möglicherweise sogar leichter wiederhergestellt werden kann.

Noch interessanter ist es, dass der ACE für CO (Creator/Owner, Ersteller/Besitzer) nicht mehr vorhanden ist. Wenn ein Benutzer also ein Objekt im Stammverzeichnis des Dateisystems erstellt, werden dem Ersteller nicht mehr besondere Berechtigungen erteilt.

Außerdem fällt auf, dass der ACE für WD (ALLE) entfernt wurde. Viele Leute, die sich für Sicherheit interessierten, die Implikationen ihrer Aktionen aber nicht völlig verstanden, waren wegen dieses ACEs grundlos besorgt. Microsoft hat jahrelang vergeblich zu erklären versucht, dass die Gruppe „ALLE“ funktional mit integrierten Benutzern praktisch identisch ist, aber am Ende diesen ACE dann doch ganz entfernt. Da es einen identischen ACE für BU (BUILTIN\Users) gibt, der ebenfalls sowohl von Containern als auch von Objekten geerbt wird, hat sich am Endergebnis im Grunde nichts geändert.

Darüber hinaus wurden zwei der ACEs für BU (integrierte Benutzer) durch ACEs für AU (authentifizierte Benutzer) ersetzt. Der Grund dafür ist, dass das Gastkonto ein Mitglied der integrierten Benutzer ist (weil INTERACTIVE ein Mitglied der integrierten Benutzer ist), GAST aber kein Mitglied der authentifizierten Benutzer ist. Um dem Gastkonto zu ermöglichen, Dateien zu lesen und auszuführen, wird dem BU weiterhin der ACE 0x1200a9 (praktisch gleichbedeutend mit Lesen und Ausführen) gewährt. Die ACEs dagegen, die Berechtigungen zum Erstellen von Dateien und Ordnern gewähren, werden authentifizierten Benutzern zugewiesen. Hier endet die Ähnlichkeit mit Windows XP. In Windows XP konnte ein GAST Dateien im Stammverzeichnis erstellen. In Windows Vista kann ein GAST solche Dateien nicht erstellen. Bedenken Sie jedoch, dass dies alles völlig irrelevant ist, es sei denn, das Gastkonto wird aktiviert und Gästen gelingt es, auf das Stammverzeichnis des Startvolumes zuzugreifen. Standardmäßig ist das Gastkonto deaktiviert.

Das Beste habe ich für den Schluss aufgehoben: In den beiden oben stehenden Listen sind ein paar sehr interessante und scheinbar problematische ACEs enthalten. In Windows XP gibt es einen ACE, der von Containern geerbt wird und für integrierte Benutzer 0x100004 lautet. Dieser ACE gewährt Benutzern das Recht, Unterordner, Unterordner von Unterordnern und so weiter zu erstellen, da er von Containern geerbt wird. Es gibt auch einen IO (Inherit-Only, nur vererben)-ACE, der von Unterordnern geerbt wird und 0x100002 lautet. Dieser ACE gewährt Benutzern das Recht, in Ordnern, die sie unterhalb des Stammverzeichnisses anlegen, Dateien und Unterordner zu erstellen. Anders ausgedrückt: diese beiden ACEs erlauben den Benutzern (einschließlich Gästen), Dateien und Ordner unter dem Stammverzeichnis zu erstellen, wie bereits weiter oben erwähnt.

In Windows Vista handelt es sich bei den entsprechenden ACEs um einen IO (Inherit-Only, nur vererben)-ACE, der sowohl von Containern als auch von Dateien geerbt wird und GR (Generic Read), GX (Generic Execute), GW (Generic Write) und SD (Read Security Descriptor) gewährt, sowie einen ACE, der nur für das Stammverzeichnis selbst gilt und die LC-Berechtigung gewährt. LC ist ein Begriff, der sich auf ACEs in Active Directory® bezieht. In Active Directory bedeutet LC, dass ein Benutzer untergeordnete Objekte auflisten kann. Der Hexadezimalwert von LC ist jedoch 0x4. 0x4 bedeutet für ein Verzeichnis FILE_ ADD_SUBDIRECTORY und ist in funktionaler Hinsicht praktisch gleichbedeutend mit 0x100004, da mit dem ACE 0x1200a9 bereits 0x100000 (die Möglichkeit, das Objekt zur Synchronisierung zu verwenden) vorliegt. Anders ausgedrückt, hat dies denselben Effekt wie in Windows XP: Benutzer können Unterverzeichnisse unter dem Stammverzeichnis erstellen.

Woher kommen die Hexadezimalwerte? Und was sind Hexadezimalwerte überhaupt? Wie Sie mittlerweile bemerkt haben, kommen in der Zugriffssteuerung ständig Hexadezimalzahlen (Zahlen mit der Basis 16) wie beispielsweise 0x1200a9 vor. Dabei handelt es sich um Bitmaskenrepräsentationen von Bits in einer Zugriffsmaske, die auf „on“ gesetzt sind, was bedeutet, dass sie im betreffenden ACE verwendet werden. Wenn Sie ein Tool wie icacls, sc oder secedit zum Auflisten einer ACL verwenden, werden die Bitmasken durch wesentlich leichter verständliche Textzeichenfolgen repräsentiert, sofern eine 1:1-Entsprechung vorliegt.

Um herauszufinden, was LC bedeutet, müssen Sie daher lediglich zur MSDN®-Website wechseln, die Zeichenfolge „LC“ suchen und in der Spalte der Zugriffsrechtswerte nach „ADS_RIGHT_ACTRL_DS_LIST“ suchen. Wenn Sie danach die Headerdatei „lads.h“ öffnen und nach dieser Zeichenfolge suchen, werden Sie feststellen, dass sie 0x4 entspricht. Bei Nicht-Active Directory-Zeichenfolgen (Zeichenfolgen, die nicht mit „ADS_RIGHT“ beginnen) finden Sie den Hexadezimalwert stattdessen normalerweise in der Datei „AccCtrl.h“. Wenn Sie den Hexadezimalwert erst einmal ermittelt haben, ist es ganz einfach, ihn in der Datei „WinNt.h“ oder „AccCtrl.h“ nachzuschlagen, um herauszufinden, was er bedeutet.

Wenn Sie dabei Hilfe benötigen, sollten Sie sich eine Ausgabe des Buchs „Protect Your Windows Network“ (von Jesper Johansson und Steve Riley, Addison-Wesley, 2005) besorgen. Darin wird in Kapitel 17 ausführlich darauf eingegangen, wie SDDL (Security Description Definition Language)-Zeichenfolgen und ACEs analysiert werden.

Die für diese Unterverzeichnisse gewährten Berechtigungen werden in Windows Vista ausschließlich vom (A;OICIIO;SDGXGWGR;;;AU)-ACE bestimmt, was den größten Unterschied zwischen Windows Vista und Windows XP ausmacht. Statt wie in Windows XP dem Ersteller von Unterverzeichnissen volle Kontrolle zu gewähren, gewährt Windows Vista authentifizierten Benutzern Änderungsberechtigungen.

Das Gesamtresultat dieser neuen ACL besteht darin, dass der Ersteller eines Objekts nicht mehr über Sonderrechte verfügt und die Dinge ein wenig klarer sind. Die vielleicht größte Änderung ist die, dass authentifizierte Benutzer sogar für Unterordner, die von Administratoren erstellt wurden, über Änderungsberechtigungen verfügen, was einen großen Unterschied zu Windows XP darstellt. In Windows XP haben Benutzer und authentifizierte Benutzer keine Rechte für Objekte, die von Administratoren unter dem Stammverzeichnis erstellt wurden. Obwohl diese ACEs auf den ersten Blick problematisch zu sein scheinen, unterscheiden sie sich in ihrer Wirkung nicht allzu sehr von der Arbeitsweise von Windows XP.

Zusammenfassend gesagt, kann in Windows Vista jeder (einschließlich des Gastbenutzers) Dateien, die sich im Stammverzeichnis befinden, lesen und ausführen. Nur authentifizierte Benutzer können neue Dateien und Ordner erstellen, und wenn Benutzer dies tun, erhalten sie Änderungsberechtigungen für diese Dateien und Ordner. Die Berechtigungen in Windows Vista sind also geringfügig strenger gefasst als in Windows XP, es sollte jedoch darauf hingewiesen werden, dass das Gastkonto standardmäßig deaktiviert ist.

Änderungen an Tokens

Wenn sich ein Benutzer anmeldet, der in Windows XP Mitglied der Gruppe „ADMINISTRATOREN“ ist, enthält sein Token die SID der Gruppe „ADMINISTRATOREN“, und er kann alles ausführen, was die Gruppe „ADMINISTRATOREN“ kann. In Windows Vista dagegen ist dies aufgrund der Benutzerkontensteuerung nicht mehr der Fall. Die Administratoren-SID ist zwar noch immer im Token enthalten, aber sie ist auf „DENY ONLY“ gesetzt, wie der Screenshot aus dem Process Explorer in Abbildung 7 zeigt.

Abbildung 7 Unter UAC wird die Administratoren-SID nur zum Verweigern des Zugriffs verwendet, es sei denn, sie wird von Ihnen erweitert.

Abbildung 7** Unter UAC wird die Administratoren-SID nur zum Verweigern des Zugriffs verwendet, es sei denn, sie wird von Ihnen erweitert. **(Klicken Sie zum Vergrößern auf das Bild)

Beim Durchführen von Zugriffssteuerung wird ein derartiger Eintrag im Token nur zum Verweigern eines Zugriffs verwendet und entspricht somit der Funktion von Verweigern-ACEs. Alle Zulassen-ACEs für diese SID werden ignoriert. Dies bedeutet, dass Sie nicht immer ein echter Administrator sind, auch wenn Sie sich als Administrator beim System anmelden.

Integritätsebenen

Windows unterstützt jetzt das Kennzeichnen von Prozessen und Objekten mit Integritätsebenen. Diese Integritätsebenen werden ebenfalls als ACEs repräsentiert, aber nicht in der DACL. Stattdessen sind sie Bestandteil der Systemzugriffssteuerungsliste (System Access Control List, SACL) und besitzen einige spezielle Flags. So wird beispielsweise das Flag NW verwendet, um anzugeben, dass ein Prozess auf einer niedrigeren Integritätsebene daran gehindert wird, in ein Objekt einer höheren Integritätsstufe zu schreiben (SDDL_NO_WRITE_UP). Mark Russinovich geht in seinem Artikel „Die Benutzerkontensteuerung von Windows Vista“ in dieser Ausgabe des TechNet Magazins ausführlicher auf dieses Thema ein.

Zusammenfassung

In Windows Vista wurde zwar keine einzige gravierende Änderung an der Zugriffssteuerung vorgenommen, wie dies bei Windows 2000 der Fall war, dafür sind zahlreiche kleinere Änderungen zu finden. Einzeln betrachtet, ist keine dieser Änderungen besonders krass. In ihrer Gesamtheit bedeuten sie aber, dass Sie die Verwaltung Ihres Systems ganz neu durchdenken müssen. Darüber hinaus unterstützen diese Änderungen eine Reihe anderer Initiativen, insbesondere die UAC und die Diensthärtung. Manche Administratoren sind zunächst sehr frustriert, wenn sie Windows Vista anfänglich verwenden. Ich habe bereits Kommentare wie „tyrannisches Betriebssystem“ gehört, da die Möglichkeit eingeschränkt wird, unerwünschte Teile des Systems zu löschen. Dennoch wurden alle Änderungen aus triftigen Gründen vorgenommen, deren Sinn bei einer genaueren Analyse des Systems offensichtlich wird.

Jesper Johansson arbeitet als Sicherheitsarchitekt für ein großes E-Commerce-Unternehmen, in dem er für Anwendungssicherheitsstrategie im Bereich Eigenschaften und Dienste zuständig ist. Er ist seit 20 Jahren im Bereich Sicherheit tätig und Autor von zahlreichen Artikeln und zwei Büchern über dieses Thema. Wenn er sich nicht gerade mit IT-Sicherheit beschäftigt, unterrichtet er Sporttauchen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.