Windows-Sicherheitsmodell für Treiberentwickler

Das Windows-Sicherheitsmodell basiert auf sicherungsfähigen Objekten. Jede Komponente des Betriebssystems muss die Sicherheit der Objekte gewährleisten, für die sie verantwortlich ist. Fahrer müssen daher die Sicherheit ihrer Geräte und Geräteobjekte schützen.

In diesem Thema wird zusammengefasst, wie das Windows-Sicherheitsmodell auf Kernelmodustreiber angewendet wird.

Windows-Sicherheitsmodell

Das Windows-Sicherheitsmodell basiert hauptsächlich auf Objektrechten mit einer geringen Anzahl systemweiter Berechtigungen. Objekte, die gesichert werden können, umfassen Prozesse, Threads, Ereignisse und andere Synchronisierungsobjekte sowie Dateien, Verzeichnisse und Geräte.

Für jeden Objekttyp werden die generischen Lese-, Schreib- und Ausführungsrechte detaillierten objektspezifischen Rechten zugeordnet. Für Dateien und Verzeichnisse sind beispielsweise das Recht zum Lesen oder Schreiben der Datei oder des Verzeichnisses, das Recht zum Lesen oder Schreiben erweiterter Dateiattribute, das Recht zum Durchlaufen eines Verzeichnisses und das Recht zum Schreiben des Sicherheitsdeskriptors eines Objekts möglich.

Das Sicherheitsmodell umfasst die folgenden Konzepte:

• Sicherheitsbezeichner (SIDs)
• Zugriffstoken
• Sicherheitsbeschreibungen:
• Zugriffssteuerungslisten (ACLs)
• Rechte

Sicherheits-IDs (SIDs)

Eine Sicherheits-ID (SID, auch als Prinzipal bezeichnet) identifiziert einen Benutzer, eine Gruppe oder eine Anmeldesitzung. Jeder Benutzer verfügt über eine eindeutige SID, die vom Betriebssystem bei der Anmeldung abgerufen wird.

SIDs werden von einer Autorität wie dem Betriebssystem oder einem Domänenserver ausgestellt. Einige SIDs sind bekannt und haben sowohl Namen als auch Bezeichner. Beispielsweise identifiziert die SID S-1-1-0 Jeden (oder Welt).

Zugriffstoken

Jeder Prozess verfügt über ein Zugriffstoken. Das Zugriffstoken beschreibt den vollständigen Sicherheitskontext des Prozesses. Sie enthält die SID des Benutzers, die SID der Gruppen, zu denen der Benutzer gehört, und die SID der Anmeldesitzung sowie eine Liste der systemweiten Berechtigungen, die dem Benutzer gewährt werden.

Standardmäßig verwendet das System das primäre Zugriffstoken für einen Prozess, wenn ein Thread des Prozesses mit einem sicherungsfähigen Objekt interagiert. Ein Thread kann jedoch die Identität eines Clientkontos annehmen. Wenn ein Thread die Identität angibt, verfügt er zusätzlich zu seinem eigenen primären Token über ein Identitätswechseltoken. Das Identitätswechseltoken beschreibt den Sicherheitskontext des Benutzerkontos, das der Thread imitiert. Der Identitätswechsel ist besonders häufig bei der Behandlung von Remoteprozeduraufrufen (REMOTE Procedure Call, RPC).

Ein Zugriffstoken, das einen eingeschränkten Sicherheitskontext für einen Thread oder Prozess beschreibt, wird als eingeschränktes Token bezeichnet. Die SIDs in einem eingeschränkten Token können nur so festgelegt werden, dass sie den Zugriff auf sicherungsfähige Objekte verweigern, nicht den Zugriff zulassen. Darüber hinaus kann das Token einen begrenzten Satz systemweiter Berechtigungen beschreiben. Die SID und identität des Benutzers bleiben identisch, aber die Zugriffsrechte des Benutzers sind eingeschränkt, während der Prozess das eingeschränkte Token verwendet. Die CreateRestrictedToken-Funktion erstellt ein eingeschränktes Token.

Sicherheitsbeschreibungen:

Jedes benannte Windows-Objekt verfügt über einen Sicherheitsdeskriptor. einige unbenannte Objekte auch. Der Sicherheitsdeskriptor beschreibt die Besitzer- und Gruppen-SIDs für das Objekt zusammen mit seinen ACLs.

Der Sicherheitsdeskriptor eines Objekts wird in der Regel von der Funktion erstellt, die das Objekt erstellt. Wenn ein Treiber die IoCreateDevice- oder IoCreateDeviceSecure-Routine aufruft , um ein Geräteobjekt zu erstellen, wendet das System einen Sicherheitsdeskriptor auf das erstellte Geräteobjekt an und legt ACLs für das Objekt fest. Für die meisten Geräte werden ACLs in der INF-Datei (Device Information) angegeben.

Weitere Informationen zu Sicherheitsbeschreibungen finden Sie in der Kerneltreiberdokumentation.

Zugriffssteuerungslisten

Access Control Listen (ACLs) ermöglichen eine differenzierte Steuerung des Zugriffs auf Objekte. Eine ACL ist Teil des Sicherheitsdeskriptors für jedes Objekt.

Jede ACL enthält null oder mehr Access Control Entries (ACE). Jeder ACE enthält wiederum eine einzelne SID, die einen Benutzer, eine Gruppe oder einen Computer identifiziert, sowie eine Liste der Rechte, die für diese SID verweigert oder zulässig sind.

ACLs für Geräteobjekte

Die ACL für ein Geräteobjekt kann auf drei Arten festgelegt werden:

• Legen Sie im Standardsicherheitsdeskriptor für den Gerätetyp fest.
• Programmgesteuert von der RtlCreateSecurityDescriptor-Funktion erstellt und durch die RtlSetDaclSecurityDescriptor-Funktion festgelegt.
• Wird in der Security Descriptor Definition Language (SDDL) in der INF-Datei des Geräts oder in einem Aufruf der IoCreateDeviceSecure-Routine angegeben.

Alle Treiber sollten SDDL in der INF-Datei verwenden, um ACLs für ihre Geräteobjekte anzugeben.

SDDL ist eine erweiterbare Beschreibungssprache, mit der Komponenten ACLs in einem Zeichenfolgenformat erstellen können. SDDL wird sowohl vom Benutzermodus als auch vom Kernelmoduscode verwendet. Die folgende Abbildung zeigt das Format von SDDL-Zeichenfolgen für Geräteobjekte.

Der Access-Wert gibt den typ des zulässigen Zugriffs an. Der SID-Wert gibt einen Sicherheitsbezeichner an, der bestimmt, für wen der Access-Wert gilt (z. B. ein Benutzer oder eine Gruppe).

Beispielsweise ermöglicht die folgende SDDL-Zeichenfolge dem System (SY) Zugriff auf alles und allen anderen Personen (WD) nur Lesezugriff:

“D:P(A;;GA;;;SY)(A;;GR;;;WD)”

Die Headerdatei wdmsec.h enthält auch einen Satz vordefinierter SDDL-Zeichenfolgen, die für Geräteobjekte geeignet sind. Die Headerdatei definiert z. B. SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX wie folgt:

"D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)"

Das erste Segment dieser Zeichenfolge ermöglicht dem Kernel und dem Betriebssystem (SY) die vollständige Kontrolle über das Gerät. Das zweite Segment ermöglicht es jedem In der integrierten Administratorengruppe (BA), auf das gesamte Gerät zuzugreifen, aber nicht die ACL zu ändern. Das dritte Segment ermöglicht jedem (WD) das Lesen oder Schreiben auf dem Gerät, und das vierte Segment gewährt dieselben Rechte für nicht vertrauenswürdigen Code (RC). Treiber können die vordefinierten Zeichenfolgen unverändert oder als Modelle für geräteobjektspezifische Zeichenfolgen verwenden.

Alle Geräteobjekte in einem Stapel sollten über die gleichen ACLs verfügen. Durch das Ändern der ACLs auf einem Geräteobjekt im Stapel werden die ACLs auf dem gesamten Gerätestapel geändert.

Das Hinzufügen eines neuen Geräteobjekts zum Stapel ändert jedoch keine ACLs, weder die des neuen Geräteobjekts (wenn es ACLs enthält) noch die der vorhandenen Geräteobjekte im Stapel. Wenn ein Treiber ein neues Geräteobjekt erstellt und an den Anfang des Stapels anfügt, sollte der Treiber die ACLs für den Stapel in das neue Geräteobjekt kopieren, indem er das Feld DeviceObject.Characteristics aus dem nächstniedrenen Treiber kopiert.

Die IoCreateDeviceSecure-Routine unterstützt eine Teilmenge von SDDL-Zeichenfolgen, die vordefinierte SIDs wie WD und SY verwenden. Benutzermodus-APIs und INF-Dateien unterstützen die vollständige SDDL-Syntax.

Sicherheitsüberprüfungen mithilfe von ACLs

Wenn ein Prozess Zugriff auf ein Objekt anfordert, vergleichen Sicherheitsüberprüfungen die ACLs für das Objekt mit den SIDs im Zugriffstoken des Aufrufers.

Das System vergleicht die ACEs in einer strengen Top-down-Reihenfolge und beendet die erste relevante Übereinstimmung. Daher sollten Sie beim Erstellen einer ACL die Verweigerungs-ACEs immer über die entsprechenden Gewährungs-ACEs setzen. Die folgenden Beispiele zeigen, wie der Vergleich abläuft.

Beispiel 1: Vergleichen einer ACL mit einem Zugriffstoken

Beispiel 1 zeigt, wie das System eine ACL mit dem Zugriffstoken für den Prozess eines Aufrufers vergleicht. Angenommen, der Aufrufer möchte eine Datei öffnen, die die in der folgenden Tabelle gezeigte ACL enthält.

Beispieldatei-ACL

Berechtigung	SID	Access
Allow	Buchhaltung	Schreiben, Löschen
Allow	Sales	Anfügen
Verweigern	Rechtliche Hinweise	Anfügen, Schreiben, Löschen
Allow	Jeder	Lesen

Diese ACL verfügt über vier ACEs, die speziell für die Gruppen Accounting, Sales, Legal und Everyone gelten.

Angenommen, das Zugriffstoken für den anfordernden Prozess enthält SIDs für einen Benutzer und drei Gruppen in der folgenden Reihenfolge:

Benutzer Jim (S-1-5-21...)

Gruppenbuchhaltung (S-1-5-22...)

Gruppenrecht (S-1-5-23...)

Alle Gruppen (S-1-1-0)

Beim Vergleichen einer Datei-ACL mit einem Zugriffstoken sucht das System zunächst nach einem ACE für Benutzer Jim in der ACL der Datei. Keiner wird angezeigt, sodass als Nächstes nach einem ACE für die Gruppe Buchhaltung gesucht wird. Wie in der vorherigen Tabelle gezeigt, wird ein ACE für die Gruppe Accounting als erster Eintrag in der ACL der Datei angezeigt, sodass Jims Prozess das Recht erhält, die Datei zu schreiben oder zu löschen, und der Vergleich wird beendet. Wenn der ACE für die Gruppe Legal stattdessen dem ACE für die Gruppe Buchhaltung in der ACL vorangestellt ist, wird dem Prozess das Schreiben, Anfügen und Löschen des Zugriffs auf die Datei verweigert.

Beispiel 2: Vergleichen einer ACL mit einem eingeschränkten Token

Das System vergleicht eine ACL mit einem eingeschränkten Token auf die gleiche Weise wie diejenigen in einem Token, das nicht eingeschränkt ist. Eine Denial-SID in einem eingeschränkten Token kann jedoch nur mit einem Deny-ACE in einer ACL übereinstimmen.

Beispiel 2 zeigt, wie das System die ACL einer Datei mit einem eingeschränkten Token vergleicht. Angenommen, die Datei weist dieselbe ACL auf, die in der vorherigen Tabelle gezeigt wurde. In diesem Beispiel verfügt der Prozess jedoch über ein eingeschränktes Token, das die folgenden SIDs enthält:

Benutzer Jim (S-1-5-21...) Verweigern

Gruppenbuchhaltung (S-1-5-22...) Verweigern

Gruppenrecht (S-1-5-23...) Verweigern

Alle Gruppen (S-1-1-0)

Die ACL der Datei listet jims SID nicht auf, sodass das System zur SID der Gruppe Buchhaltung übergeht. Obwohl die ACL der Datei über ein ACE für die Gruppe "Buchhaltung" verfügt, ermöglicht dieser ACE den Zugriff. Daher stimmt sie nicht mit der SID im eingeschränkten Token des Prozesses überein, das den Zugriff verweigert. Daraufhin wird das System zur Sid der Gruppe Legal übergegangen. Die ACL für die Datei enthält einen ACE für die Gruppe Legal, der den Zugriff verweigert, sodass der Prozess die Datei nicht schreiben, anfügen oder löschen kann.

Rechte

Ein Benutzer kann einen systembezogenen Vorgang auf dem lokalen Computer ausführen, z. B. das Laden eines Treibers, das Ändern der Zeit oder das Herunterfahren des Systems.

Berechtigungen unterscheiden sich von Zugriffsrechten, da sie für systembezogene Aufgaben und Ressourcen anstelle von Objekten gelten und weil sie einem Benutzer oder einer Gruppe von einem Systemadministrator und nicht vom Betriebssystem zugewiesen werden.

Das Zugriffstoken für jeden Prozess enthält eine Liste der Dem Prozess gewährten Berechtigungen. Berechtigungen müssen vor der Verwendung ausdrücklich aktiviert sein. Weitere Informationen zu Berechtigungen finden Sie unter Berechtigungen in der Kerneltreiberdokumentation.

Windows-Sicherheitsmodellszenario: Erstellen einer Datei

Das System verwendet die im Windows-Sicherheitsmodell beschriebenen Sicherheitskonstrukte, wenn ein Prozess ein Handle für eine Datei oder ein Objekt erstellt.

Das folgende Diagramm zeigt die sicherheitsbezogenen Aktionen, die ausgelöst werden, wenn ein Benutzermodusprozess versucht, eine Datei zu erstellen.

Das vorherige Diagramm zeigt, wie das System reagiert, wenn eine Benutzermodusanwendung die CreateFile-Funktion aufruft. Die folgenden Hinweise beziehen sich auf die eingekreisten Zahlen in der Abbildung:

1. Eine Anwendung im Benutzermodus ruft die CreateFile-Funktion auf und übergibt einen gültigen Microsoft Win32-Dateinamen.
2. Der Benutzermodus Kernel32.dll übergibt die Anforderung an Ntdll.dll, wodurch der Win32-Name in einen Microsoft Windows NT-Dateinamen konvertiert wird.
3. Ntdll.dll ruft die NtCreateFile-Funktion mit dem Windows-Dateinamen auf. Innerhalb Ntoskrnl.exe verarbeitet der E/A-Manager NtCreateFile.
4. Der E/A-Manager packt die Anforderung in einen Objekt-Manager-Aufruf neu.
5. Der Objekt-Manager löst symbolische Links auf und stellt sicher, dass der Benutzer über Durchlaufrechte für den Pfad verfügt, in dem die Datei erstellt wird. Weitere Informationen finden Sie unter Sicherheitsüberprüfungen im Objekt-Manager.
6. Der Objekt-Manager ruft die Systemkomponente auf, die den zugrunde liegenden Objekttyp besitzt, der der Anforderung zugeordnet ist. Bei einer Dateierstellungsanforderung ist diese Komponente der E/A-Manager, der Geräteobjekte besitzt.
7. Der E/A-Manager überprüft den Sicherheitsdeskriptor für das Geräteobjekt anhand des Zugriffstokens für den Prozess des Benutzers, um sicherzustellen, dass der Benutzer über den erforderlichen Zugriff auf das Gerät verfügt. Weitere Informationen finden Sie unter Sicherheitsüberprüfungen im E/A-Manager.
8. Wenn der Benutzerprozess über den erforderlichen Zugriff verfügt, erstellt der E/A-Manager ein Handle und sendet eine IRP_MJ_CREATE Anforderung an den Treiber für das Gerät oder Dateisystem.
9. Der Treiber führt nach Bedarf zusätzliche Sicherheitsüberprüfungen durch. Wenn die Anforderung beispielsweise ein Objekt im Namespace des Geräts angibt, muss der Treiber sicherstellen, dass der Aufrufer über die erforderlichen Zugriffsrechte verfügt. Weitere Informationen finden Sie unter Sicherheitsüberprüfungen im Treiber.

Sicherheitsprüfungen im Objekt-Manager

Die Verantwortung für die Überprüfung von Zugriffsrechten liegt bei der Komponente auf höchster Ebene, die solche Überprüfungen durchführen kann. Wenn der Objekt-Manager die Zugriffsrechte des Aufrufers überprüfen kann, tut er dies. Andernfalls übergibt der Objekt-Manager die Anforderung an die Komponente, die für den zugrunde liegenden Objekttyp verantwortlich ist. Diese Komponente überprüft wiederum den Zugriff, sofern möglich; Wenn dies nicht möglich ist, übergibt sie die Anforderung an eine noch niedrigere Komponente, z. B. einen Treiber.

Der Objekt-Manager überprüft ACLs auf einfache Objekttypen, z. B. Ereignisse und Mutexsperren. Für Objekte, die über einen Namespace verfügen, führt der Typbesitzer Sicherheitsüberprüfungen durch. Der E/A-Manager gilt beispielsweise als Typbesitzer für Geräteobjekte und Dateiobjekte. Wenn der Objekt-Manager beim Analysieren eines Namens den Namen eines Geräteobjekts oder Dateiobjekts findet, übergibt er den Namen an den E/A-Manager, wie im oben beschriebenen Szenario zur Erstellung der Datei. Der E/A-Manager überprüft dann die Zugriffsrechte, sofern möglich. Wenn der Name ein Objekt in einem Gerätenamespace angibt, schaltet der E/A-Manager in den Namen an den Gerätetreiber (oder dateisystem) aus, und dieser Treiber ist für die Überprüfung des angeforderten Zugriffs verantwortlich.

Sicherheitsprüfungen im E/A-Manager

Wenn der E/A-Manager ein Handle erstellt, überprüft er die Rechte des Objekts anhand des Prozesszugriffstokens und speichert dann die dem Benutzer gewährten Rechte zusammen mit dem Handle. Wenn später E/A-Anforderungen eintreffen, überprüft der E/A-Manager die dem Handle zugeordneten Rechte, um sicherzustellen, dass der Prozess das Recht hat, den angeforderten E/A-Vorgang auszuführen. Wenn der Prozess beispielsweise später einen Schreibvorgang anfordert, überprüft der E/A-Manager die dem Handle zugeordneten Rechte, um sicherzustellen, dass der Aufrufer Schreibzugriff auf das Objekt hat.

Wenn das Handle dupliziert ist, können Rechte aus der Kopie entfernt, aber nicht hinzugefügt werden.

Wenn der E/A-Manager ein Objekt erstellt, konvertiert er generische Win32-Zugriffsmodi in objektspezifische Rechte. Beispielsweise gelten die folgenden Rechte für Dateien und Verzeichnisse:

Win32-Zugriffsmodus	Objektspezifische Rechte
GENERIC_READ	ReadData
GENERIC_WRITE	WriteData
GENERIC_EXECUTE	ReadAttributes
GENERIC_ALL	Alle

Um eine Datei zu erstellen, muss ein Prozess über Durchlaufrechte für die übergeordneten Verzeichnisse im Zielpfad verfügen. Um beispielsweise \Device\CDROM0\Directory\File.txt zu erstellen, muss ein Prozess das Recht haben, "\Device", "\Device\CDROM0" und "\Device\CDROM0\Directory" zu durchlaufen. Der E/A-Manager überprüft nur die Durchlaufrechte für diese Verzeichnisse.

Der E/A-Manager überprüft die Durchlaufrechte, wenn er den Dateinamen analysiert. Wenn der Dateiname ein symbolischer Link ist, löst der E/A-Manager ihn in einen vollständigen Pfad auf und überprüft dann die Durchlaufrechte, beginnend mit dem Stamm. Angenommen, der symbolische Link \DosDevices\D wird dem Windows NT-Gerätenamen \Device\CDROM0 zugeordnet. Der Prozess muss über Durchlaufrechte für das Verzeichnis \Device verfügen.

Weitere Informationen finden Sie unter Objekthandles und Objektsicherheit.

Sicherheitsüberprüfungen im Treiber

Der Betriebssystemkern behandelt jeden Treiber tatsächlich als Dateisystem mit eigenem Namespace. Wenn ein Aufrufer daher versucht, ein Objekt im Gerätenamespace zu erstellen, überprüft der E/A-Manager, ob der Prozess über Durchlaufrechte für die Verzeichnisse im Pfad verfügt.

Bei WDM-Treibern führt der E/A-Manager keine Sicherheitsüberprüfungen für den Namespace durch, es sei denn, das Geräteobjekt wurde erstellt und gibt FILE_DEVICE_SECURE_OPEN an. Wenn FILE_DEVICE_SECURE_OPEN nicht festgelegt ist, ist der Treiber dafür verantwortlich, die Sicherheit seines Namespace zu gewährleisten. Weitere Informationen finden Sie unter Steuern des Gerätenamespacezugriffs und Schützen von Geräteobjekten.

Bei WDF-Treibern ist das Flag FILE_DEVICE_SECURE_OPEN immer festgelegt, sodass die Sicherheitsbeschreibung des Geräts überprüft wird, bevor eine Anwendung auf namen im Namespace des Geräts zugreifen kann. Weitere Informationen finden Sie unter Steuern des Gerätezugriffs in KMDF-Treibern.

Windows-Sicherheitsgrenzen

Treiber, die miteinander und mit Anrufern im Benutzermodus mit unterschiedlichen Berechtigungsstufen kommunizieren, können als über eine Vertrauensgrenze betrachtet werden. Eine Vertrauensgrenze ist ein beliebiger Codeausführungspfad, der von einem Prozess mit niedrigeren Berechtigungen in einen Prozess mit höherer Berechtigung kreuzt.

Je höher die Diskrepanz in den Berechtigungsstufen ist, desto interessanter ist die Grenze für Angreifer, die Angriffe wie einen Angriff auf die Rechteerweiterung gegen den zielführenden Treiber oder Prozess ausführen möchten.

Ein Teil des Erstellungsprozesses eines Bedrohungsmodells besteht darin, die Sicherheitsgrenzen zu untersuchen und nach unerwarteten Pfaden zu suchen. Weitere Informationen finden Sie unter Bedrohungsmodellierung für Treiber.

Alle Daten, die eine Vertrauensgrenze überschreiten, sind nicht vertrauenswürdig und müssen überprüft werden.

Dieses Diagramm zeigt drei Kerneltreiber und zwei Apps, eine in einem App-Container und eine App, die mit Administratorrechten ausgeführt wird. Die roten Linien zeigen beispielweise Vertrauensgrenzen an.

Da der App-Container zusätzliche Einschränkungen bieten kann und nicht auf Administratorebene ausgeführt wird, ist Pfad (1) ein Risikopfad für einen Eskalationsangriff, da die Vertrauensgrenze zwischen einem App-Container (einem Prozess mit sehr geringen Berechtigungen) und einem Kerneltreiber liegt.

Pfad (2) ist ein Pfad mit geringerem Risiko, da die App mit Administratorrechten ausgeführt wird und direkt in den Kerneltreiber aufruft. Admin ist bereits eine ziemlich hohe Berechtigung auf dem System, sodass die Angriffsfläche vom Administrator zum Kernel weniger ein interessantes Ziel für Angreifer ist, aber dennoch eine bemerkenswerte Vertrauensgrenze.

Pfad (3) ist ein Beispiel für einen Codeausführungspfad, der mehrere Vertrauensgrenzen überschreitet, die übersehen werden könnten, wenn kein Bedrohungsmodell erstellt wird. In diesem Beispiel gibt es eine Vertrauensgrenze zwischen Treiber 1 und Treiber 3, da Treiber 1 Eingaben aus der Benutzermodus-App akzeptiert und direkt an Treiber 3 übergibt.

Alle Eingaben, die aus dem Benutzermodus in den Treiber gelangen, sind nicht vertrauenswürdig und sollten überprüft werden. Eingaben von anderen Treibern können auch nicht vertrauenswürdig sein, je nachdem, ob der vorherige Treiber nur ein einfaches Passthrough war (z. B. wurden Daten von Treiber 1 von App 1 empfangen , Treiber 1 hat keine Überprüfung der Daten durchgeführt und sie einfach an Treiber 3 weitergeleitet). Stellen Sie sicher, dass Sie alle Angriffsflächen und Vertrauensgrenzen identifizieren und alle Daten überprüfen, die diese überschreiten, indem Sie ein vollständiges Bedrohungsmodell erstellen.

Windows-Sicherheit Modellempfehlungen

• Legen Sie starke Standard-ACLs in Aufrufen der IoCreateDeviceSecure-Routine fest.
• Geben Sie acLs in der INF-Datei für jedes Gerät an. Diese ACLs können bei Bedarf enge Standard-ACLs lockern.
• Legen Sie die FILE_DEVICE_SECURE_OPEN Merkmal fest, um Geräteobjektsicherheitseinstellungen auf den Gerätenamespace anzuwenden.
• Definieren Sie keine IOCTLs, die FILE_ANY_ACCESS zulassen, es sei denn, ein solcher Zugriff kann nicht böswillig ausgenutzt werden.
• Verwenden Sie die IoValidateDeviceIoControlAccess-Routine , um die Sicherheit für vorhandene IOCTLS zu erhöhen, die FILE_ANY_ACCESS.
• Erstellen Sie ein Bedrohungsmodell, um die Sicherheitsgrenzen zu untersuchen und nach unerwarteten Pfaden zu suchen. Weitere Informationen finden Sie unter Bedrohungsmodellierung für Treiber.
• Weitere Empfehlungen zur Treibersicherheit finden Sie unter Checkliste für die Treibersicherheit.

Weitere Informationen

Schützen von Geräteobjekten

Sicherheitscheckliste für Treiber