Behandeln des Clientidentitätswechsels in UMDF 1.x-Treibern

UMDF-Treiber werden normalerweise unter dem LocalService-Konto ausgeführt und können nicht auf Dateien oder Ressourcen zugreifen, die Benutzeranmeldeinformationen erfordern, z. B. geschützte Dateien oder andere geschützte Ressourcen. Ein UMDF-Treiber funktioniert in der Regel für Befehle und Daten, die zwischen einer Clientanwendung und einem Gerät fließen. Daher greifen die meisten UMDF-Treiber nicht auf geschützte Ressourcen zu.

Einige Treiber erfordern jedoch möglicherweise Zugriff auf eine geschützte Ressource. Ein UMDF-Treiber kann beispielsweise Firmware aus einer Datei, die eine Clientanwendung bereitstellt, in ein Gerät laden. Die Datei kann über eine Zugriffssteuerungsliste (Access Control List, ACL) verfügen, die verhindert, dass nicht autorisierte Benutzer die Datei ändern und die Kontrolle über das Gerät übernehmen. Leider verhindert diese ACL auch den Zugriff des UMDF-Treibers auf die Datei.

Das Framework bietet eine Identitätswechselfunktion, die es Treibern ermöglicht, die Identität des Treiberclients zu imitieren und die Zugriffsrechte des Clients auf geschützte Ressourcen abzurufen.

Aktivieren des Identitätswechsels

Sowohl das Installationspaket des UMDF-Treibers als auch die Clientanwendung müssen die Identitätswechselfunktion des Frameworks wie folgt aktivieren:

• Die INF-Datei des Installationspakets des UMDF-Treibers muss die UmdfImpersonationLevel-Direktive enthalten und die maximal zulässige Identitätswechselebene festlegen. Der Identitätswechsel ist nur aktiviert, wenn die INF-Datei die UmdfImpersonationLevel-Direktive enthält. Weitere Informationen zum Festlegen der Identitätswechselebene finden Sie unter Angeben von WDF-Direktiven in INF-Dateien.

• Die Clientanwendung muss die zulässige Identitätswechselebene für jedes Dateihandle festlegen. Die Anwendung verwendet die QoS-Einstellungen (Quality of Service) in der Microsoft Win32 CreateFile-Funktion , um die zulässige Identitätswechselebene festzulegen. Weitere Informationen zu diesen Einstellungen finden Sie im DwFlagsAndAttributes-Parameter von CreateFile in der Windows SDK-Dokumentation.

Behandeln des Identitätswechsels für eine E/A-Anforderung

Der UMDF-Treiber und das Framework behandeln den Identitätswechsel für eine E/A-Anforderung in der folgenden Sequenz:

1. Der Treiber ruft die IWDFIoRequest::Impersonate-Methode auf, um die erforderliche Identitätswechselebene und eine IImpersonateCallback::OnImpersonate-Rückruffunktion anzugeben.

2. Das Framework überprüft die angeforderte Identitätswechselebene. Wenn die angeforderte Ebene größer als die Ebene ist, die das Installationspaket des UMDF-Treibers und die Clientanwendung zulassen, schlägt die Identitätswechselanforderung fehl. Andernfalls gibt das Framework die Identität des Clients an und ruft sofort die Rückruffunktion OnImpersonate auf.

Die OnImpersonate-Rückruffunktion darf nur die Vorgänge ausführen, die die angeforderte Identitätswechselebene erfordern, z. B. das Öffnen einer geschützten Datei.

UMDF erlaubt es der OnImpersonate-Rückruffunktion eines Treibers nicht, eine der Objektmethoden des Frameworks aufzurufen. Dadurch wird sichergestellt, dass der Treiber die Identitätswechselebene nicht für andere Treiberrückruffunktionen oder andere Treiber verfügbar macht.

Hinweis In den Versionen 1.0 bis 1.7 von UMDF gewährt IWDFIoRequest::Impersonate die höchste Identitätswechselebene, die die Clientanwendung und die INF-Datei zulassen, auch wenn die Identitätswechselebene, die der Treiber anfordert, niedriger ist. In UMDF-Versionen 1.9 und höher gewährt die Impersonate-Methode nur die Identitätswechselebene, die der Treiber anfordert.

Übergeben von Anmeldeinformationen im Treiberstapel

Wenn Ihr Treiber eine vom Typ WdfRequestCreate typisierte E/A-Anforderung empfängt, leitet der Treiber die E/A-Anforderung möglicherweise im Treiberstapel an einen Kernelmodustreiber weiter. Kernelmodustreiber verfügen nicht über die Identitätswechselfunktion, die IWDFIoRequest::Impersonate für UMDF-basierte Treiber bereitstellt.

Wenn sie also möchten, dass ein Kernelmodustreiber die Benutzeranmeldeinformationen des Clients (sondern die Anmeldeinformationen des Treiberhostprozesses) empfängt, muss der Treiber das WDF_REQUEST_SEND_OPTION_IMPERSONATE_CLIENT-Flag festlegen, wenn er IWDFIoRequest::Send aufruft, um die Erstellungsanforderung an das E/A-Ziel zu senden. Die Send-Methode gibt einen Fehlercode zurück, wenn der Identitätswechselversuch fehlschlägt, es sei denn, der Treiber legt auch das WDF_REQUEST_SEND_OPTION_IMPERSONATION_IGNORE_FAILURE-Flag fest.

Der Treiber muss IWDFIoRequest::Impersonate nicht aufrufen, bevor er die Anforderung an das E/A-Ziel sendet.

Wenn Treiber der unteren Ebene auch die Anforderung weiterleiten, wird die Identitätswechselebene des Clients den Treiberstapel hinuntergestreift.

Reduzieren von Sicherheitsbedrohungen

Um die Wahrscheinlichkeit eines Angriffs auf Rechteerweiterungen zu verringern, sollten Sie Folgendes ausführen:

• Versuchen Sie, den Identitätswechsel zu vermeiden.

  Um beispielsweise den Identitätswechsel zum Öffnen einer Datei zu vermeiden, die der Treiber verwenden muss, kann die Clientanwendung die Datei öffnen und E/A-Vorgänge verwenden, um Dateiinhalte an den Treiber zu senden.

• Verwenden Sie die niedrigste Identitätswechselebene, die Ihr Treiber erfordert.

  Legen Sie die Identitätswechselebene in der INF-Datei Ihres Treibers so niedrig wie möglich fest. Wenn Ihr Treiber keinen Identitätswechsel erfordert, schließen Sie die UmdfImpersonationLevel-Direktive nicht in die INF-Datei ein.

• Minimieren Sie die Möglichkeiten eines Angreifers, Ihren Treiber auszunutzen.

  Ihre OnImpersonate-Rückruffunktion sollte einen kleinen Codeabschnitt enthalten, der nur den Vorgang ausführt, der einen Identitätswechsel erfordert. Wenn Ihr Treiber beispielsweise auf eine geschützte Datei zugreift, ist ein Identitätswechsel nur erforderlich, wenn das Dateihandle geöffnet wird. Es ist kein Identitätswechsel erforderlich, um aus der Datei zu lesen oder in diese zu schreiben.