Windows-Sicherheitsmodell für Treiberentwickler
Das Windows-Sicherheitsmodell basiert auf sicherungsfähigen Objekten. Jede Komponente des Betriebssystems muss die Sicherheit der Objekte sicherstellen, für die sie verantwortlich ist. Treiber 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 in erster Linie auf Objektrechten mit einer kleinen Anzahl systemweiter Berechtigungen. Objekte, die gesichert werden können, umfassen – sind aber nicht beschränkt auf – Prozesse, Threads, Ereignisse und andere Synchronisierungsobjekte sowie Dateien, Verzeichnisse und Geräte.
Für jeden Objekttyp werden die generischen Lese-, Schreib- und Ausführungsrechte in detaillierte objektspezifische Rechte zugeordnet. Mögliche Rechte 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.
Das Sicherheitsmodell umfasst die folgenden Konzepte:
- Sicherheitskennungen (SIDs)
- Zugriffstoken
- Sicherheitsbeschreiber
- Zugriffssteuerungslisten (ACLs)
- Berechtigungen
Sicherheitskennungen (SIDs)
Eine Sicherheitskennung (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 Domain-Server ausgestellt. Einige SIDs sind bekannt und weisen Namen sowie Bezeichner auf. Beispielsweise identifiziert die SID S-1-1-0 jeden (oder die 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 imitieren. Wenn ein Thread eine Identität vornimmt, 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 als Identitätswechsel angibt. Identitätswechsel werden insbesondere bei der Remoteprozeduraufrufbehandlung (RPC) verwendet.
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 der Zugriff auf sicherungsfähige Objekte verweigert und nicht zugelassen wird. Darüber hinaus kann das Token einen begrenzten Satz systemweiter Berechtigungen beschreiben. Die SID und die Identität des Benutzers sind gleich Standard 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.
Sicherheitsbeschreiber
Jedes benannte Windows-Objekt verfügt über einen Sicherheitsdeskriptor; einige nicht benannte 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 Sicherheitsdeskriptoren finden Sie in der Kerneltreiberdokumentation.
Zugriffssteuerungslisten
Zugriffssteuerungslisten (Access Control Lists, ACLs) ermöglichen eine differenzierte Kontrolle über den Zugriff auf Objekte. Eine ACL ist Teil des Sicherheitsdeskriptors für jedes Objekt.
Jede ACL enthält null oder mehr Zugriffssteuerungseinträge (Access Control Entries, ACE). Jede ACE enthält wiederum eine einzelne SID, die einen Benutzer, eine Gruppe oder einen Computer identifiziert, und 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 den Standardsicherheitsdeskriptor für den Gerätetyp fest.
- Programmgesteuert von der RtlCreateSecurityDescriptor-Funktion erstellt und von der RtlSetDaclSecurityDescriptor-Funktion festgelegt.
- Angegeben in der Security Descriptor Definition Language (SDDL) in der INF-Datei des Geräts oder in einem Aufruf der Routine IoCreateDeviceSecure-Routine.
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 den Systemzugriff (SY) auf alles und ermöglicht 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 das vollständige Steuern des Kernels und Betriebssystems (SY) über das Gerät. Im zweiten Segment kann jeder in der integrierten Administratorengruppe (BA) auf das gesamte Gerät zugreifen, aber nicht die ACL ändern. Das dritte Segment ermöglicht jedem (WD) das Lesen oder Schreiben auf das Gerät, und das vierte Segment gewährt denselben Rechten 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 dieselben ACLs aufweisen. Wenn Sie die ACLs auf einem Geräteobjekt im Stapel ändern, werden die ACLs im gesamten Gerätestapel geändert.
Das Hinzufügen eines neuen Geräteobjekts zum Stapel ändert jedoch keine ACLs, entweder die des neuen Geräteobjekts (sofern es ACLs enthält) oder die eines vorhandenen Geräteobjekts 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 das Feld "DeviceObject.Characteristics " vom nächsten unteren Treiber kopiert wird.
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 den 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 stoppt bei der ersten relevanten Übereinstimmung. Beim Erstellen einer ACL sollten Sie daher die Ablehnungs-ACEs immer über die entsprechenden Gewährungs-ACEs setzen. Die folgenden Beispiele zeigen, wie der Vergleich fortgesetzt wird.
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. Gehen Sie davon aus, dass der Aufrufer eine Datei öffnen möchte, die über die ACL verfügt, die in der folgenden Tabelle angezeigt wird.
ACL-Dateibeispiel
| Berechtigung | SID | Access |
|---|---|---|
| Zulassen | Buchhaltung | Schreiben, Löschen |
| Zulassen | Sales | Anfügen |
| Verweigern | Rechtliche Hinweise | Anfügen, Schreiben, Löschen |
| Zulassen | Jeder | Lesen Sie |
Diese ACL verfügt über vier ACEs, die speziell für die Gruppen "Accounting", "Sales", "Legal" und "Everyone" gelten.
Gehen Sie als Nächstes davon aus, dass das Zugriffstoken für den Anforderungsprozess SIDs für einen Benutzer und drei Gruppen in der folgenden Reihenfolge enthält:
Benutzer Jim (S-1-5-21...)
Gruppenbuchhaltung (S-1-5-22...)
Gruppenrecht (S-1-5-23...)
Gruppe "Jeder" (S-1-1-0)
Beim Vergleichen einer Datei-ACL mit einem Zugriffstoken sucht das System zunächst nach einer ACE für Benutzer Jim in der ACL der Datei. Es wird keins angezeigt, daher wird als Nächstes nach einem ACE für die Buchhaltungsgruppe gesucht. Wie in der vorherigen Tabelle gezeigt, wird ein ACE für die Gruppe „Accounting“ als erster Eintrag in der ACL der Datei angezeigt. Daher erhält Jims Prozess das Recht, die Datei zu schreiben oder zu löschen, und der Vergleich wird beendet. Wenn der ACE für die Gruppe "Legal" stattdessen der ACE für die Buchhaltungsgruppe in der ACL vorausging, würde der Prozess schreib-, anfügen und löschen-Zugriff 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 sie diese in einem Token vergleicht, das nicht eingeschränkt ist. Eine Verweigerungs-SID in einem eingeschränkten Token kann jedoch nur mit einer Verweigerungs-ACE in einer ACL übereinstimmen.
Beispiel 2 zeigt, wie das System die ACL einer Datei mit einem eingeschränkten Token vergleicht. Gehen Sie davon aus, dass die Datei dieselbe ACL aufweist, die in der vorherigen Tabelle angezeigt wird. In diesem Beispiel weist der Prozess jedoch ein eingeschränktes Token auf, 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
Gruppe "Jeder" (S-1-1-0)
Die ACL der Datei listet die SID von Jim nicht auf, sodass das System mit der Sid der Buchhaltungsgruppe fortfährt. Obwohl die ACL der Datei einen ACE für die Accounting-Gruppe hat, gestattet dieser ACE den Zugriff. Aus diesem Grund stimmt er nicht mit der SID im eingeschränkten Token des Prozesses überein, wodurch der Zugriff verweigert wird. Daher fährt das System mit der SID der Gruppe "Legal" fort. Die ACL für die Datei enthält eine ACE für die Gruppe "Legal", die den Zugriff verweigert, sodass der Prozess die Datei nicht schreiben, anfügen oder löschen kann.
Berechtigungen
Ein Privileg ist das Recht, dass ein Benutzer einen systembezogenen Vorgang auf dem lokalen Computer ausführt, z. B. einen Treiber lädt, die Zeit ändert oder das System heruntergefahren wird.
Berechtigungen unterscheiden sich von Zugriffsrechten, da sie für systembezogene Aufgaben und Ressourcen anstelle von Objekten gelten und einem Benutzer oder einer Gruppe von einem Systemadministrator anstelle des Betriebssystems zugewiesen werden.
Das Zugriffstoken für jeden Prozess enthält eine Liste der Berechtigungen, die dem Prozess gewährt werden. Berechtigungen müssen vor der Verwendung ausdrücklich aktiviert sein. Weitere Informationen zu Berechtigungen finden Sie in der Kerneltreiberdokumentation unter Berechtigungen.
Windows-Sicherheitsmodellszenario: Erstellen einer Datei
Das System verwendet die im Windows-Sicherheitsmodell beschriebenen Sicherheitskonstrukte, wenn ein Prozess einen 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:
- Eine Benutzermodusanwendung ruft die CreateFile-Funktion auf und übergibt einen gültigen Microsoft Win32-Dateinamen.
- Der Benutzermodus Kernel32.dll übergibt die Anforderung an Ntdll.dll, wodurch der Win32-Name in einen Microsoft Windows NT-Dateinamen konvertiert wird.
- Ntdll.dll ruft die NtCreateFile-Funktion mit dem Windows-Dateinamen auf. Innerhalb Ntoskrnl.exe verarbeitet der E/A-Manager NtCreateFile.
- Der E/A-Manager packt die Anforderung in einen Objekt-Manager-Aufruf um.
- Der Objekt-Manager löst symbolische Verknüpfungen auf und stellt sicher, dass der Benutzer über Traversalrechte für den Pfad verfügt, in dem die Datei erstellt wird. Weitere Informationen finden Sie unter Sicherheitsüberprüfungen im Objekt-Manager.
- 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.
- 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.
- 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.
- Der Treiber führt bei 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.
Sicherheitsüberprüfungen im Objekt-Manager
Die Verantwortung für die Überprüfung von Zugriffsrechten gehört zur Komponente der höchsten Ebene, die solche Prüfungen durchführen kann. Wenn der Objekt-Manager die Zugriffsrechte des Aufrufers überprüfen kann, geschieht dies. Wenn nicht, übergibt der Objekt-Manager die Anforderung an die Komponente, die für den zugrunde liegenden Objekttyp verantwortlich ist. Diese Komponente wiederum überprüft den Zugriff, falls dies möglich ist; Wenn dies nicht möglich ist, wird die Anforderung an eine noch niedrigere Komponente übergeben, z. B. an einen Treiber.
Der Objekt-Manager überprüft ACLs auf einfache Objekttypen, z. B. Ereignisse und Mutex-Locks. Bei Objekten mit einem Namespace führt der Typbesitzer Sicherheitsüberprüfungen durch. Der E/A-Manager wird beispielsweise als Typbesitzer für Geräteobjekte und Dateiobjekte betrachtet. Wenn der Objekt-Manager beim Analysieren eines Namens den Namen eines Geräteobjekts oder eines Dateiobjekts findet, übergibt er den Namen an den E/A-Manager, wie im oben dargestellten Szenario für die Dateierstellung. Der E/A-Manager überprüft dann die Zugriffsrechte, falls dies möglich ist. Wenn der Name ein Objekt innerhalb eines Geräte-Namespaces angibt, übergibt der E/A-Manager den Namen wiederum an den Geräte- (oder Dateisystem-)Treiber, und dieser Treiber ist für die Validierung des angeforderten Zugriffs verantwortlich.
Sicherheitsüberprü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 eingehen, überprüft der E/A-Manager die Rechte, die dem Handle zugeordnet sind, um sicherzustellen, dass der Prozess das Recht hat, den angeforderten E/A-Vorgang auszuführen. Wenn der Prozess später beispielsweise einen Schreibvorgang anfordert, überprüft der E/A-Manager die rechte, die dem Handle zugeordnet sind, um sicherzustellen, dass der Aufrufer Schreibzugriff auf das Objekt hat.
Wenn das Handle dupliziert ist, können die 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. Die folgenden Rechte gelten beispielsweise für Dateien und Verzeichnisse:
| Win32-Zugriffsmodus | Objektspezifische Rechte |
|---|---|
| GENERIC_READ | ReadData |
| GENERIC_WRITE | WriteData |
| GENERIC_EXECUTE | ReadAttributes |
| GENERIC_ALL | Alle |
Zum Erstellen einer Datei muss ein Prozess über Traversalrechte für die übergeordneten Verzeichnisse im Zielpfad verfügen. Um beispielsweise \Device\CDROM0\Directory\File.txt zu erstellen, muss ein Prozess berechtigt sein, \Device, \Device\CDROM0 und \Device\CDROM0\Directory zu durchlaufen. Der E/A-Manager überprüft nur die Traversalrechte für diese Verzeichnisse.
Der E/A-Manager überprüft Traversalrechte, 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 Traversalrechte, beginnend mit dem Stamm. Nehmen wir beispielsweise an, dass die symbolische Verknüpfung \DosDevices\D dem Windows NT-Gerätenamen \Device\CDROM0 zugeordnet ist. Der Prozess muss über Traversalrechte für das Verzeichnis \Device verfügen.
Weitere Informationen finden Sie unter Objekthandles und Objektsicherheit.
Sicherheitsüberprüfungen im Treiber
Der Betriebssystem-Kernel behandelt jeden Treiber tatsächlich als Dateisystem mit seinem eigenen Namespace. Wenn ein Aufrufer versucht, ein Objekt im Gerätenamespace zu erstellen, überprüft der E/A-Manager daher, dass der Prozess über Traversalrechte 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 Device-Objekt wurde erstellt, um FILE_DEVICE_SECURE_OPEN anzugeben. Wenn FILE_DEVICE_SECURE_OPEN nicht festgelegt ist, ist der Treiber dafür verantwortlich, die Sicherheit des Namespaces sicherzustellen. Weitere Informationen finden Sie unter Steuern des Gerätenamespacezugriffs und sichern von Geräteobjekten.
Bei WDF-Treibern ist das FILE_DEVICE_SECURE_OPEN-Flag immer festgelegt, sodass eine Überprüfung der Sicherheitsbeschreibung des Geräts erfolgt, 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
Bei der Kommunikation von Treibern untereinander und mit Benutzermodus-Anrufern mit unterschiedlichen Berechtigungsstufen kann davon ausgegangen werden, dass sie eine Vertrauensgrenze überschreiten. Eine Vertrauensgrenze ist ein beliebiger Codeausführungspfad, der von einem niedrigeren privilegierten Prozess in einen Prozess mit höheren Privilegierten überschreitet.
Je höher die Unterschiede in den Berechtigungsstufen sind, desto interessanter ist die Grenze für Angreifer, die Angriffe wie einen Berechtigungseskalationsangriff auf den zielbezogenen Treiber oder Prozess ausführen möchten.
Ein Teil des Prozesses zum Erstellen 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 geben Beispiel-Vertrauensgrenzen an.
Da der App-Container zusätzliche Einschränkungen bereitstellen kann und nicht auf Administratorebene ausgeführt wird, stellt Pfad (1) ein höheres Risiko für einen Eskalationsangriff dar, da die Vertrauensgrenze zwischen einem App-Container (einem Prozess mit sehr geringen Berechtigungen) und einem Kernel-Treiber liegt.
Pfad (2) ist ein Pfad mit geringerem Risiko, da die App mit Administratorrechten ausgeführt wird und direkt in den Kerneltreiber aufruft. Der Administrator ist bereits eine ziemlich hohe Berechtigung auf dem System, sodass die Angriffsfläche von Administrator zu Kernel weniger von einem interessanten Ziel für Angreifer ist, aber dennoch eine bemerkenswerte Vertrauensgrenze ist.
Pfad (3) ist ein Beispiel für einen Codeausführungspfad, der mehrere Vertrauensgrenzen überschreitet, die verpasst werden können, 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 übernimmt 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. Daten wurden von Treiber 1 von App 1 empfangen, Treiber 1 hat keine Überprüfung der Daten ausgeführt und nur an Treiber 3 weitergeleitet). Achten Sie darauf, alle Angriffsflächen und Vertrauensgrenzen zu identifizieren und alle Daten zu überprüfen, die sie überschreiten, indem Sie ein vollständiges Bedrohungsmodell erstellen.
Windows-Sicherheitsmodell-Empfehlungen
- 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 das Merkmal FILE_DEVICE_SECURE_OPEN fest, um Sicherheitseinstellungen für Geräteobjekt 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 zulassen.
- 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 in der Checkliste zur Treibersicherheit.