Anwenden von Sicherheitsbeschreibungen auf das Geräteobjekt

Die meisten Treiber verwenden die Zugriffssteuerungen, die vom E/A-Manager für ihre Geräteobjekte angewendet werden, um sich vor unangemessenem Zugriff zu schützen. Der einfachste Ansatz für die meisten Treiber besteht darin, einen expliziten Sicherheitsdeskriptor anzuwenden, wenn der Treiber installiert wird. In einer INF-Datei werden solche Sicherheitsbeschreibungen durch den Eintrag "Sicherheit" im Abschnitt AddReg beschrieben. Weitere Informationen zur vollständigen Sprache, die zum Beschreiben von Sicherheitsbeschreibungen verwendet wird, finden Sie unter Security Descriptor Definition Language in der Microsoft Windows SDK-Dokumentation.

Das grundlegende Format eines Sicherheitsdeskriptors, der die Security Descriptor Definition Language (SDDL) verwendet, enthält die folgenden unterschiedlichen Teile eines Standardsicherheitsdeskriptors:

• Die Besitzer-SID.

• Die Gruppen-SID.

• Die DACL (Discretionary Access Control List).

• Die SACL (System Access Control List).

Daher lautet die Beschreibung in einem INF-Skript für einen Sicherheitsdeskriptor wie folgt:

O:owner-sidG:group-sidD:dacl-flags(ace)(ace)S:sacl-flags(ace)(ace)

Die einzelnen Zugriffssteuerungseinträge beschreiben den Zugriff, der einer bestimmten Gruppe oder einem bestimmten Benutzer gewährt oder verweigert werden soll, wie in der Sicherheits-ID oder SID angegeben. Eine INF-Datei kann z. B. eine Zeile wie folgendes enthalten:

"D:P(A;CI;GR;;;BU)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;NS)(A;CI;GA;;;LS)(A;CI;CCDCLCSWRPSDRC;;;S-1-5-32-556)"

Das obige Beispiel stammt aus einem NETTCPIP. INF-Datei von einem Microsoft Windows XP Service Pack 1(SP1)-System.

In diesem instance ist kein Besitzer oder eine Gruppe angegeben, sodass standardmäßig die vordefinierten Werte oder Standardwerte verwendet werden. D gibt an, dass es sich um eine DACL handelt. Das P gibt an, dass dies eine geschützte ACL ist und keine Rechte vom Sicherheitsdeskriptor des enthaltenden Objekts erbt. Die geschützte ACL verhindert, dass eine mildere Sicherheit für das übergeordnete Element vererbt wird. Der Klammerausdruck gibt einen einzelnen Zugriffssteuerungseintrag (Single Access Control Entry, ACE) an. Ein Zugriffssteuerungseintrag, der die SDDL verwendet, besteht aus mehreren unterschiedlichen, durch Semikolons getrennten Komponenten. In der Reihenfolge sind sie wie folgt:

• Der Typindikator für den ACE. Es gibt vier eindeutige Typen für DACLs und vier verschiedene Typen für SACLs.

• Das Feld "Flags ", das verwendet wird, um die Vererbung dieses ACE für untergeordnete Objekte oder die Überwachungs- und Alarmrichtlinie für SACLs zu beschreiben.

• Das Rechtefeld gibt an, welche Rechte vom ACE gewährt oder verweigert werden. Dieses Feld kann entweder einen bestimmten numerischen Wert angeben, der die generischen, Standard- und spezifischen Rechte angibt, die für diesen ACE gelten, oder eine Zeichenfolgenbeschreibung der allgemeinen Zugriffsrechte verwenden.

• Eine Objekt-GUID, wenn die DACL eine objektspezifische ACE-Struktur ist.

• Eine geerbte Objekt-GUID, wenn die DACL eine objektspezifische ACE-Struktur ist

• Eine SID, die die Sicherheitsentität angibt, für die dieser ACE gilt.

Bei der Interpretation des Beispielsicherheitsdeskriptors gibt das vor dem ACE führende "A" an, dass dies ein "Zugriff zugelassen"-Eintrag ist. Die Alternative ist ein Eintrag "Zugriff verweigert", der nur selten verwendet wird und durch ein führendes "D"-Zeichen gekennzeichnet wird. Das Feld flags gibt container inherit (CI) an, was angibt, dass dieses ACE von Unterobjekten geerbt wird.

Die Rechtefeldwerte codieren bestimmte Rechte, die generische Rechte und Standardrechte enthalten. Beispielsweise gibt "GR" den Zugriff "generischer Lesezugriff" und "GA" den Zugriff auf "generic all" an, bei denen es sich bei beiden um generische Rechte handelt. Auf diese generischen Rechte folgen eine Reihe von Sonderrechten. Im obigen Beispiel gibt "CC" den untergeordneten Zugriff erstellen an, der spezifisch für Datei- und Verzeichnisrechte ist. Das obige Beispiel umfasst auch andere Standardrechte nach der CC-Zeichenfolge, einschließlich "DC" für das Löschen des untergeordneten Zugriffs, "LC" für untergeordneten Zugriff auf die Liste, "SW" für selbstrechtigen Zugriff, "RP" für Zugriff auf Leseeigenschaften, "SD" für standardmäßigen Löschzugriff und "RC" für lesesteuerungszugriff.

Die SID-Eintragszeichenfolgen im obigen Beispiel umfassen "PU" für Poweruser, "BU" für integrierte Benutzer, "BA" für "integrierte Administratoren", "LS" für das lokale Dienstkonto, "SY" für das lokale System und "NS" für das Netzwerkdienstkonto. Im obigen Beispiel erhalten Benutzer also generischen Lesezugriff auf das -Objekt. Im Gegensatz dazu erhalten integrierte Administratoren, das lokale Dienstkonto, das lokale System und der Netzwerkdienst generischen Zugriff (Lesen, Schreiben und Ausführen). Der vollständige Satz aller möglichen Rechte und Standard-SID-Zeichenfolgen ist im Windows SDK dokumentiert.

Diese ACLs werden auf alle Geräteobjekte angewendet, die von einem bestimmten Treiber erstellt wurden. Ein Treiber kann beim Erstellen eines benannten Geräteobjekts auch die Sicherheitseinstellungen bestimmter Objekte mithilfe der neuen Funktion IoCreateDeviceSecure steuern. Die IoCreateDeviceSecure-Funktion ist unter Windows XP Service Pack 1 und Windows Server 2003 und höher verfügbar. Mithilfe von IoCreateDeviceSecure wird der sicherheitsdeskriptor, der auf das Geräteobjekt angewendet werden soll, mithilfe einer Teilmenge der vollständigen Sicherheitsdeskriptordefinitionssprache beschrieben, die für Geräteobjekte geeignet ist.

Der Zweck der Anwendung bestimmter Sicherheitsbeschreibungen auf Geräteobjekte besteht darin, sicherzustellen, dass angemessene Sicherheitsüberprüfungen für das Gerät durchgeführt werden, wenn eine Anwendung versucht, auf das Gerät selbst zuzugreifen. Für Geräteobjekte, die eine Namensstruktur (z. B. den Namespace eines Dateisystems) enthalten, gehören die Details zum Verwalten des Zugriffs auf diesen Gerätenamespace dem Treiber, nicht dem E/A-Manager.

Ein interessantes Problem in diesen Fällen ist die Handhabung der Sicherheit an der Grenze zwischen dem E/A-Manager, der für die Überprüfung des Zugriffs auf das Treibergerätobjekt verantwortlich ist, und dem Gerätetreiber, der jede für den Treiber geeignete Sicherheitsrichtlinie implementiert. Wenn das geöffnete Objekt der Name des Geräts selbst ist, führt der E/A-Manager normalerweise eine Vollständige Zugriffsüberprüfung für das Geräteobjekt direkt mithilfe des Sicherheitsdeskriptors durch. Wenn das geöffnete Objekt jedoch einen Pfad innerhalb des Treibers selbst angibt, überprüft der E/A-Manager nur, um sicherzustellen, dass dem Geräteobjekt traverse-Zugriff gewährt wird. In der Regel wird dieses Durchlaufrecht gewährt, weil den meisten Threads SeChangeNotifyPrivilege gewährt wurde, was dem Gewähren des Durchlaufrechts für das Verzeichnis entspricht. Ein Gerät, das die Namensstruktur nicht unterstützt, fordert normalerweise an, dass der E/A-Manager eine vollständige Sicherheitsüberprüfung durchführt. Dies erfolgt durch Festlegen des FILE_DEVICE_SECURE_OPEN Bits im Feld Geräteeigenschaften. Ein Treiber, der eine Mischung aus solchen Geräteobjekten enthält, sollte dieses Merkmal für geräte festlegen, die die Namensstruktur nicht unterstützen. Beispielsweise würde ein Dateisystem diese Option für sein benanntes Geräteobjekt festlegen (das keine Namensstruktur unterstützt), aber diese Option nicht für seine unbenannten Geräteobjekte (z. B. ein Volume), die die Namensstruktur unterstützen. Wenn dieses Bit nicht richtig festgelegt werden kann, ist ein häufiger Fehler in Treibern und kann unangemessenen Zugriff auf das Gerät zulassen. Für Treiber, die die Attachment-Schnittstelle (z. B. IoAttachDeviceToDeviceStackSafe) verwenden, wird das FILE_DEVICE_SECURE_OPEN Bit festgelegt, wenn dieses Feld auf dem Gerät festgelegt ist, an das der Treiber anfügt. Filtertreiber müssen sich also keine Gedanken über diesen speziellen Aspekt der Sicherheitsüberprüfung machen.