Sicherheit auf dem PrüfstandTools zum Verwalten von ACLs
Jesper M. Johansson
In Windows bieten Zugriffssteuerungslisten (Access Control Lists, ACLs) eine äußerst detaillierte Steuerung der Fähigkeiten von Benutzern und Prozessen beim Verwenden von Ressourcen wie Dateien und Ordnern. Das Verwalten von ACLs kann eine der komplexeren Aufgaben im Zusammenhang mit dem Sicherheitsschutz für die Systeme Ihrer Benutzer sein. Glücklicherweise gibt es eine Reihe nützlicher Dienstprogramme,
die beim Automatisieren und Vereinfachen von Aufgaben im Zusammenhang mit Berechtigungen und ACLs helfen.
Die meisten Leser werden mit dem cacls.exe-Tool vertraut sein, das in jeder Version von Windows NT® seit der Erstveröffentlichung enthalten ist. Wenn Sie cacls.exe in Windows Vista™ ausführen, erhalten Sie die folgende Begrüßungsnachricht:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cacls
NOTE: Cacls is now deprecated, please use Icacls.
Zusätzlich zu den Updates bei ACLs in Windows Vista (die im TechNet Magazin vom Juni 2007 erörtert wurden – siehe technetmagazine.com/issues/ 2007/06), hat Microsoft ebenfalls verschiedene Tools zum Verwalten von ACLs aktualisiert. Interessanterweise handelt es sich bei den wichtigsten Updates um Befehlszeilentools.
Icacls.exe ist neu in Windows Vista (und auch in der Vorgängerversion Windows Server® 2003 Service Pack 2). Icacls.exe soll cacls.exe zu einem späteren Zeitpunkt ersetzen. Wie Sie vielleicht wissen, wurde cacls.exe nie vollständig aktualisiert, um die fein abgestimmten Berechtigungen zu unterstützen, die mit Windows® 2000 eingeführt wurden. Es handelt sich also hierbei um ein Update, das etwa sieben Jahre überfällig ist.
Obwohl cacls.exe veraltet ist, umfasst es überraschenderweise einige neue Features. Erstens kennt das Tool Verknüpfungspunkte und symbolische Verknüpfungen und kann sie übertragen. Zweitens kann es eine ACL mithilfe einer SDDL-Zeichenfolge (Security Description Definition Language) sowohl drucken als auch einrichten.
Doch trotz der Updates bei cacls.exe benötigen Sie die Funktionen von icacls.exe.
Speichern und Wiederherstellen von ACLs
Einer meiner nie erfüllten Wünsche der letzten 10 Jahre war die Möglichkeit, eine ACL zu speichern, sodass sie zu einem späteren Zeitpunkt wiederhergestellt werden kann. Dies ist einer der komplexesten Vorgänge, die Sie bei ACLs durchführen können. Mit Ausnahme bestimmter Sonderfälle ist es unwahrscheinlich, dass Sie genau dasselbe Ergebnis erhalten, das Sie erhalten hätten, wenn Sie die ACLs nicht zerstört hätten. Dennoch kann diese Funktion recht nützlich sein.
Bevor dargelegt wird, wie ACLs gespeichert oder wiederhergestellt werden, soll zunächst erläutert werden, warum dies so schwer ist. Angenommen Sie haben eine Hierarchie, die Benutzerdaten für Studenten an einer örtlichen Hochschule enthält. Sie speichern die ACL am 1. Februar. Am 17. April stellen Sie fest, dass die ACL beschädigt wurde, und begeben sich daran, sie aus der gespeicherten Kopie wiederherzustellen. Welche Komplikationen könnte es bei diesem Vorgang geben?
Erstens hat das neue Quartal am 2. April begonnen. Ungefähr 15 Prozent der Studenten haben ihr Studium abgeschlossen, sodass ihre Verzeichnisse nicht mehr existieren. Daher liegen in der Sicherungsdatei ungültige ACLs vor. Außerdem hat eine Reihe neuer Studenten (weitere 15 Prozent) im neuen Quartal ihr Studium aufgenommen. Diese verfügen jetzt über Basisverzeichnisse, aber keine ACLs in der Sicherungsdatei. Wie sollten ihre ACLs aussehen? Dann gibt es natürlich noch die 70 Prozent vorhandener Studenten, doch viele haben neue Dateien und Ordner erstellt und andere gelöscht. Die gelöschten Elemente können ignoriert werden, doch wie lassen sich die neu erstellten Ordner konfigurieren? Was geschieht, wenn ein Student am 4. März beschlossen hat, einen Ordner für seine Freunde freizugeben? Wird dies blockiert, wenn Sie die ACL wiederherstellen?
Das Speichern und Wiederherstellen von ACLs ist keinesfalls so einfach, wie es oft dargestellt wird. Sie müssen dabei äußerst vorsichtig vorgehen. Es ist möglich und sogar wahrscheinlich, dass es dadurch zu einem nicht definierten Verhalten kommt. Das Wiederherstellen von ACLs ist auf jeden Fall der letzte Ausweg. Je länger die letzte Sicherung zurückliegt, desto wahrscheinlicher ist es, dass bei einer Wiederherstellung etwas zerstört wird.
Wenn Sie diese Funktion trotzdem ausprobieren möchten, führen Sie icacls.exe mit dem /save-Schalter aus:
icacls <target> /save acls.bin /t
Dabei werden die ACLs in einer Datei namens „acls.bin“ gespeichert. Die Datei enthält eine Zeile für jedes Objekt mit einer ACL, gefolgt von einer Zeile, die die ACL in SDDL spezifiziert. Mithilfe des /t-Schalters wirkt sich der Befehl auf das von Ihnen bestimmte Objekt und alle Objekte und Container darunter aus.
Die Speicherfunktion ist eine willkommene Erweiterung des Toolkit, doch sie weist einige Fehler auf. So speichert sie beispielsweise nur die freigegebene Zugriffssteuerungsliste (DACL), nicht die Systemzugriffssteuerungsliste (SACL). Wenn eine SACL vorhanden ist, speichert die Funktion einen unechten Wert, der darauf hinweist, aber von der SACL an sich wird kein Teil gespeichert.
Außerdem führt die Art und Weise, wie die ACL gespeichert wird, zu einem interessanten Problem. Bevor Sie die gespeicherte ACL in einem Texteditor Ihrer Wahl öffnen, sollten Sie sich unbedingt an Folgendes halten:
Bearbeiten Sie die gespeicherte ACL nicht!
Wenn die Datei mit der gespeicherten ACL in einem Texteditor geöffnet wird, wird sie anscheinend als Unicode (UTF-16)-formatierte Textdatei angezeigt. Tatsächlich trifft dies fast zu. Das könnte Sie dazu verleiten, die Datei zu bearbeiten und in einem Texteditor zu speichern. Tun Sie dies auf keinen Fall!
Wenn Sie die Datei, die die gespeicherten ACLs enthält, in einem Texteditor öffnen und dann speichern, können Sie die ACLs aus dieser Datei nicht wiederherstellen. Es stellt sich nämlich heraus, dass es sich nicht um eine Unicode-Textdatei handelte. Eine solche Datei muss mit dem aus 2 Bytes bestehenden 0xfffe beginnen. Wenn Sie die Datei mit einem Texteditor wie Editor speichern, wird dieses Kennzeichen in die ersten 2 Bytes gesetzt. Das icacls.exe-Tool erwartet jedoch, dass die ACL-Daten bei Byte 0 in der Datei beginnen. Daher kann das Tool die ACLs in der Datei nicht analysieren, da es erwartet, dass die ersten zwei Bytes Teil der Zeichenfolge sind, die das Objekt angibt, an dem der Befehl durchgeführt werden soll. Ihre Sicherungsdatei ist unbrauchbar.
Microsoft ist sich dieses Problems bewusst, doch da es erst sehr spät im Betazyklus für Windows Vista gemeldet wurde, wurde dieser Fehler nicht vor der Veröffentlichung behoben. Bisher ist nicht bekannt, wann oder ob der Fehler überhaupt behoben wird. Daher ist es am besten, gespeicherte ACLs nicht zu bearbeiten. Wenn dies unbedingt erforderlich ist, speichern Sie die Datei als BIN-Datei, und verwenden Sie einen Hexadezimaleditor, beispielsweise Ihre bevorzugte Entwicklungsumgebung.
Wenn Sie eine ACL mit dem /save-Schalter gespeichert haben, können Sie sie mithilfe von icacls.exe mit dem /restore-Schalter wiederherstellen. Der Wiederherstellungsbefehl verwendet in seiner einfachsten Form diese Syntax:
icacls <directory> /restore acls.bin
Das Wiederherstellungsverfahren wirkt sich nicht auf Dateien aus. Sehen Sie sich dazu die Befehlsfolge in Abbildung 1 an. Durch Verweisen von icacls.exe auf eine Datei wird eine Speicherdatei erstellt. Dann wird die Wiederherstellung versucht, indem /save einfach durch /restore ersetzt wird. Dies funktioniert nicht, da sich der Wiederherstellungsbefehl nur auf Verzeichnisse auswirkt. Die Dateien, die geändert werden sollen, sind bereits in der acls.bin-Datei angegeben. Zum Wiederherstellen der ACL muss auf das Verzeichnis statt auf die Datei verwiesen werden. Die erfolgt im letzten Befehl, in dem „.“ als das Objekt angegeben wird, an dem die Funktion durchgeführt werden soll.
Figure 1 Speichern und Wiederherstellen von ACLs
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files
C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Es ist außerdem zu beachten, dass der Wiederherstellungsbefehl erweitert ausgeführt werden muss. Sie können den Speicherbefehl von einer Eingabeaufforderung für einen Administrator mit niedrigen Rechten oder sogar als Standardbenutzer ausführen, solange Sie das Recht haben, die ACL zu lesen. Zum Wiederherstellen der ACL benötigen Sie jedoch ein vollständiges, unverfälschtes Administratortoken.
Ersetzen von SIDs
Ein weiteres sehr nützliches Feature von icacls.exe ist die Möglichkeit, die Berechtigungen für einen Benutzer durch Berechtigungen für einen anderen Benutzer zu ersetzen. Dies geschieht während der Wiederherstellung mit dem /substitute-Schalter. In der Dokumentation für den Ersetzungsschalter wird eine SID gefordert, doch dann wird erläutert, dass es sich auch um einen normalen Benutzernamen handeln kann. Daher funktioniert die in Abbildung 2 dargestellte Folge.
Figure 2 Ersetzen von SIDs während der Wiederherstellung
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
VistaRC2-Test\Jesper:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
Successfully processed 1 files; Failed processing 0 files
Das Ergebnis ist also dieselbe ACL wie zuvor, doch der ACE, der Berechtigungen für „foo“ angegeben hat, gibt sie nun stattdessen für „bar“ an.
Ändern eines Besitzers
Das chown-Tool ist seit Jahren wichtiger Bestandteil von UNIX-Systemen. In Windows gab es ursprünglich keine integrierte Möglichkeit, den Besitzer eines Objekts zu ändern. Dann wurde das setowner-Tool im Resource Kit entwickelt. Später gab es das takeown.exe-Tool in Windows NT 4.0, doch dieses Dienstprogramm ermöglichte es dem Benutzer nur, den Besitz zu übernehmen. Der Betreffende konnte anderen das Besitzrecht nicht gewähren, es sei denn, er verfügte über das entsprechende Kennwort. Jetzt bietet icacls.exe die integrierte Möglichkeit, für Objekte, bei denen Sie diese Berechtigung haben, den Besitzer festzulegen.
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Leider kann icacls.exe den Besitzer eines Objekts nicht anzeigen. Es gibt von der Befehlszeile aus keine Möglichkeit zu sehen, wer der Besitzer eines Objekts ist. Zudem wird der Besitzer des Objekts nicht gespeichert, wenn Sie die ACL für ein Objekt speichern.
Bei icacls.exe ist zudem ein Fehler vorhanden, da SeTakeOwnershipPrivilege nicht aufgerufen wird, um den Besitzer zu ändern. Wenn Sie das Recht haben, den Besitzer eines Objekts auf der Grundlage der ACL zu ändern, funktioniert icacls.exe wie vorgesehen. Doch wenn Sie Administrator, aber nicht berechtigt sind, den Besitzer auf der Grundlage der ACL des Objekts zu ändern, können Sie icacls.exe aufgrund dieses Fehlers nicht dazu verwenden. In diesem Fall müssen Sie das takeown.exe-Tool verwenden, das SeTakeOwnershipPrivilege aufruft, aber Sie können nur den Besitzer in Ihr Konto oder die Administratorengruppe und nicht in ein beliebiges Konto umändern:
C:\>takeown /f c:\test
SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Weiterhin ist das subinacl-Tool zu erwähnen, das im Microsoft-Downloadcenter heruntergeladen werden kann und über einen setowner-Schalter verfügt. Subinacl arbeitet in vielen Fällen intuitiver als icacls, ist aber komplizierter in der Verwendung.
Suchen von Dateien für einen bestimmten Benutzer
Icacls bietet eine weitere nützliche Funktion: Das Tool kann für die Suche nach Dateien eingesetzt werden, die Berechtigungen für bestimmte Benutzer enthalten. Beispiel:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t
SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Dies könnte hilfreich sein, um festzustellen, worauf ein bestimmter Benutzer Zugriff hat.
Zurücksetzen und Ändern von ACLs
Wenn eine ACL beschädigt oder zerstört wurde, bietet icacls.exe eine Möglichkeit, sie zurückzusetzen, sodass sie vom übergeordneten Element erbt. Dies wäre beim Zero-Day-Sicherheitsproblem äußerst nützlich gewesen, das im Herbst 2006 eintrat. Eine Methode, das Problem in einer Windows-Komponente zu begrenzen, bestand darin, allen den Zugriff auf das Objekt zu verweigern. Dies war relativ einfach, doch das Entfernen des Zugriffssteuerungseintrags (Access Control Entry, ACE) war mithilfe der in Windows XP und Windows Server 2003 integrierten Tools fast unmöglich. Doch in Windows Vista kann einfach der folgende Befehl ausgeführt werden:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset
processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
Icacls.exe verfügt selbstverständlich über alle standardmäßigen grant-/deny-/remove-Vorgänge. Das einzige wirklich neue Element in dieser Liste ist „remove“. Mithilfe dieses Schalters können Sie alle allow-ACEs, alle deny-ACEs oder beides für einen bestimmten Benutzer aus einem bestimmten Objekt oder einer Hierarchie entfernen. Abbildung 3 zeigt Beispiele für einige andere grant-, remove- und deny-Vorgänge.
Figure 3 Grant-, deny- und remove-Vorgänge
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
Die Möglichkeit, nur die deny-ACEs zu entfernen, kann nützlich sein, wenn Sie einer bestimmten Gruppe oder einem Benutzer Zugriff auf ein Objekt gewähren möchten.
Festlegen von Integritätsebenen
Icacls.exe bietet auch die Möglichkeit, Integritätsebenen anzuzeigen und festzulegen. Windows Vista unterstützt die Angabe von Integritätsbeschriftungen bei Objekten. Dies erfolgt mit dem Befehlszeilentool icacls.exe:
C:\>icacls c:\test /setintegritylevel high
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Mandatory Label\High Mandatory Level:(NW)
Successfully processed 1 files; Failed processing 0 files
Beachten Sie, dass icacls.exe eine Integritätsbeschriftung nur anzeigt, wenn eine solche für das Objekt ausdrücklich festgelegt wurde. Bei den meisten Dateien ist dies nicht der Fall.
Außerdem kann icacls.exe überprüfen, ob ein Objekt über eine kanonische ACL verfügt. Wie bereits erwähnt, stellen manche Drittanbietertools ACEs in der falschen Reihenfolge in ACLs. Mithilfe von icacls.exe können solche Probleme, wie hier dargestellt, überprüft und behoben werden:
C:\>icacls c:\test /verify
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
ACL-Benutzeroberfläche
Die ACL-Benutzeroberfläche wurde gegenüber der Benutzeroberfläche in Windows XP leicht geändert. In Abbildungen 4 und 5 ist der Dialog auf der ACL-Benutzeroberfläche in Windows XP beziehungsweise Windows Vista dargestellt.
Abbildung 4** Dialog auf der ACL-Benutzeroberfläche in Windows XP **
Abbildung 5** Dialog auf der ACL-Benutzeroberfläche in Windows Vista **
Wie Sie sehen, wurden hier einige Änderungen vorgenommen. Zum einen ist im Dialog das Objekt, an dem Sie arbeiten, deutlich zu erkennen. Dies kann nützlich sein, wenn Sie an mehreren Objekten gleichzeitig arbeiten. Zweitens ist unten ein Hyperlink zu einer Hilfe vorhanden. Als größte Änderung wurden die Schaltflächen „Hinzufügen“ und „Entfernen“ entfernt und durch die Schaltfläche „Bearbeiten“ ersetzt. Diese dient zur Unterstützung der Benutzerzugriffssteuerung (User Access Control, UAC) in Windows Vista. Wie anhand des Schildsymbols auf der Schaltfläche ersichtlich ist, ist der Benutzer, der diesen Dialog gestartet hat, nicht zum Bearbeiten der ACL berechtigt und muss daher vor dem Bearbeiten von Berechtigungen erweiterten Zugriff erhalten. Beachten Sie, dass dies keine standardmäßige Einstellung ist, wenn Sie einen Ordner im Stamm von Laufwerk C: erstellen und sofort die Eigenschaften überprüfen. Als Besitzer des Ordners haben Sie implizite Berechtigungen zum Bearbeiten der ACL. Das Schildsymbol wird in diesem Fall nicht angezeigt. Das Schildsymbol stellt einen COM-Moniker dar, also einen Mechanismus, der zum Starten einer Benutzeraufforderung für einen Teil eines Prozesses dient, der ausgeführt wird. Wenn Sie auf die Schaltfläche „Bearbeiten“ klicken, wird der Ihnen bekannte Erweiterungsdialog angezeigt, und wenn Sie im Erweiterungsdialog auf „Weiter“ klicken, wird ein Dialog angezeigt, der fast identisch mit dem in Windows XP durch Klicken auf die Schaltfläche „Hinzufügen“ angezeigten Dialogs ist. In der ACL-Benutzeroberfläche tritt dieses Doppeldialogkonzept an mehreren Stellen auf: Ein Dialog wird so lange angezeigt, bis eine Erweiterung durchgeführt wurde. Wenn dies erfolgt ist, wird der vertraute Dialog aus früheren Versionen von Windows angezeigt.
Wenn Sie auf die Schaltfläche „Erweitert“ und anschließend auf die Registerkarte „Überwachung“ klicken, wird immer eine Erweiterungsschaltfläche angezeigt, wie in Abbildung 6 dargestellt. Sie können die Überwachung nicht ohne Erweiterung ändern, selbst wenn Sie vollständige Kontrolle über das Objekt haben und der Besitzer sind. Dies ist darauf zurückzuführen, dass die Möglichkeit zum Ändern einer Objekt-SACL mithilfe der SE_SECURITY_NAME-Berechtigung geregelt wird, was bei den Tools der grafischen Benutzeroberfläche als „Verwalten von Überwachungs- und Sicherheitsprotokollen“ bezeichnet wird. Nur Administratoren verfügen standardmäßig über dieses Recht. Die Berechtigung wird jedoch bei einem Administrator im Administratorbestätigungsmodus (Admin Approval Mode) entfernt (wenn UAC aktiviert ist), sodass die Erweiterung erforderlich ist, selbst wenn Sie Administrator sind.
Abbildung 6** Zum Modifizieren von Überwachungseinstellungen in Windows Vista ist immer eine Erweiterung erforderlich. **
Ein letzter Hinweis zu den Erweiterungsanforderungen beim Ändern von ACLs: Alle diese Anweisungen hängen davon ab, dass Sie die Benutzerzugriffssteuerung nicht deaktivieren. Wenn Sie UAC deaktivieren, wird der Zustand wie in Windows XP mit Ausnahme der anders aussehenden Dialoge wiederhergestellt. Es ist jedoch keine Erweiterung erforderlich, vorausgesetzt Sie melden sich als Administrator an, da Ihr Token jetzt immer die Administratoren-SID enthält.
Weitere Tools
Icacls.exe ist ein sehr nützliches Tool und eine erhebliche Verbesserung gegenüber cacls.exe, doch es sind immer noch einige Unzulänglichkeiten vorhanden. Der vielleicht größte Mangel liegt darin, dass nur auf Objekte zugegriffen werden kann, wenn es sich um Dateien und Verzeichnisse handelt. Windows Vista nimmt im Vergleich zu Windows XP geringe Änderungen an den ACLs anderer Objekte vor, aber in bestimmten Fällen sollte es Ihnen möglich sein, ACLs in einem Dienst, einem Registrierungsschlüssel oder sogar einem Active Directory®-Objekt zu verwalten.
Wenn Sie ein Anhänger von Befehlszeilen sind, brauchen Sie dazu subinacl.exe. Subinacl.exe ist in den Supporttools enthalten und auch als Download verfügbar.
Es muss allerdings angemerkt werden, dass die Verwendung von subinacl.exe nicht ganz einfach ist. Bisweilen scheint das Tool sogar ziemlich beschränkt zu sein. Subinad.exe dagegen ist ein unglaublich leistungsfähiges Tool zum Verwalten der Zugriffssteuerung. Jeder Poweradministrator benötigt dieses Tool.
Registrierungs-ACLs
Bei den Registrierungs-ACLs hat es genau wie bei den Dateisystem-ACLs Änderungen gegeben. Die Änderungen sind jedoch vom Umfang her sehr viel geringer als beim Dateisystem. Der augenfälligste Unterschied gegenüber früheren Versionen von Windows besteht darin, dass aufgrund der veralteten Poweruserfunktion fast keine Poweruser-ACEs mehr vorhanden sind. Poweruser haben nicht mehr Berechtigungen als andere Benutzer. Es ist jedoch ein Beweis für die Komplexität von ACLs, dass nicht alle ACEs für Poweruser abgeschafft wurden. Ein paar wurden leider übersehen.
In den ACLs in der Registrierung wird Ihnen an einigen Stellen ein ACE für eine SID mit der Bezeichnung RESTRICTED auffallen. Dies ist zwar keine Neuerung in Windows Vista, aber trotzdem eine interessante und oft falsch verstandene SID. Die RESTRICTED-SID kennzeichnet einen Prozess, der ein eingeschränktes Token enthält. Ein eingeschränktes Token wird mithilfe eines besonderen Features der CreateRestrictedToken-API erstellt. Aus einem solchen Token resultieren eine oder mehrere einschränkende SIDs, die in einer separaten Zugriffsüberprüfung verwendet werden. Angenommen ein Prozess wird mit einem eingeschränkten Token ausgeführt. Wenn dieser Prozess versucht, auf ein Objekt mit einem ACE für die RESTRICTED-SID zuzugreifen, führt Windows zwei Zugriffsüberprüfungen durch. Die erste ist die normale Zugriffsüberprüfung. Die zweite funktioniert genau wie erste, wird aber nur bei den eingeschränkten SIDs im Token durchgeführt. Beide Zugriffsüberprüfungen müssen erfolgreich ausgeführt werden.
Derzeit gibt es mehrere ACLs, die die RESTRICTED-SID verwenden, speziell in der Registrierung. Der Screenshot einer solchen ACL ist in Abbildung 7 dargestellt.
Abbildung 7** Die Registrierungs-ACLs umfassen an mehreren Stellen einen ACE für RESTRICTED. **
Derzeit nutzen nur wenige Prozesse die eingeschränkte Tokenfunktion, besonders im Zusammenhang mit einschränkenden SIDs. Ein Beispiel für einen Prozess, der diese Funktion verwendet, ist der Dienstprozess, der die Windows Firewall, das Basisfiltermodul und den Diagnoserichtliniendienst hostet. Er verwendet auch ein Token mit eingeschränktem Schreiben. Auf Grundlage meiner Ermittlungen verwenden derzeit nur neun Dienste RESTRICTED-Tokens und Tokens mit eingeschränktem Schreiben in Windows Vista.
Wie bei Neuausgaben vorheriger Versionen von Windows sollte in Bezug auf Registrierungsberechtigungen sehr vorsichtig vorgegangen werden. Mit Ausnahme von außergewöhnlichen, sehr speziellen Umständen sollten Berechtigungen in der Registrierung nicht geändert werden. Aufgrund des komplizierten Vererbungsmodells und der vertraulichen Daten in der Registrierung erhöht sich die Wahrscheinlichkeit eines schwerwiegenden Fehlers erheblich, wenn Sie ACLs in der Registrierung unbedacht ändern.
Zusammenfassung
Wie bei den meisten Versionen von Windows gibt es auch bei Windows Vista geringfügige Änderungen bei der Zugriffssteuerung. Doch im Unterschied zu anderen neuen Versionen sind viele kleinere Änderungen vorhanden, die zusammen zu einer bedeutenden Verhaltensänderung führen. Besonders bei UAC waren mehrere Änderungen erforderlich, z. B. die Integritätsbeschriftungen und Änderungen an der ACL-Benutzeroberfläche. Außerdem wurde die bisher erste größere Bereinigung bei ACLs vorgenommen.
In vielerlei Hinsicht wurden die standardmäßigen Windows-ACLs in Windows Vista vereinfacht, was etwas völlig Neues ist. Doch wie bei vorherigen Versionen sollten Sie bei der Zugriffssteuerung sehr vorsichtig vorgehen, wenn Sie nicht über eingehende Kenntnisse auf diesem Gebiet verfügen. Dies gilt besonders für neue Versionen des Betriebssystems. Es bleibt zu hoffen, dass Ihnen die in diesem Artikel erörterten Tools eine gründlichere Untersuchung von ACLs erleichtern.
Jesper M. Johansson ist Principal Security Engineer, der an Problemen mit der Softwaresicherheit arbeitet und redaktionelle Beiträge für das TechNet Magazin schreibt. Er verfügt über einen Ph.D. in MIS und kann auf mehr als 20 Jahre Erfahrung in der Computersicherheit zurückblicken. Dieser Artikel beruht auf dem neuen Buch von Roger Grimes und Jesper Johansson mit dem Titel Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.