CODEWITHSUNDEEP
uwpdrivercapabilityumdf
Jer Yango
Jer Yango

Reputation: 592

Limit driver access only to UWP app with CustomCapability + Signed SCCD

I have a UMDF driver that provides IOCTL commands to be accessed by the UWP application. The UWP application is submitted to the store, complete with the appropriate custom capability and signed SCCD in order to access the UMDF driver.

What I understand from the SCCD MS documentation is that this allows the UWP app to access the driver and its IOCTLs, so when other UWP apps try to gain access, they would be rejected. However, the SCCD does not explicitly state that Win32 applications are still able to access the IOCTLs, which I think defeats the purpose of having the custom capability and SCCD.

Given this problem, I understand I have to reject requests coming from Win32 apps in another way.

There is this GetApplicationUserModelId function that we wanted to use to determine if the app is not a UWP app. This requires the pID, and we can get it using WdfRequestGetRequestorProcessId. However, obtaining a process handle for this pID requires accessing the memory of other processes. With the UMDF driver having no privilege because it does not own the process, an ERROR_ACCESS_DENIED is being returned when trying to to call OpenProcess, even with an access right of PROCESS_QUERY_LIMITED_INFORMATION.

OpenProcess documentation suggests that in order to open a handle to another local process and obtain full access rights, we must enable the SeDebugPrivilege privilege. I believe doing this puts the driver into a greater security risk and because of this, it may not be a good idea to push through.

Should there be another alternative to this approach, or another type of descriptor, or anything similar that could support the goal of restricting win32 apps from using the IOCTLs?

Upvotes: 0

Views: 217

Answers (1)

Jer Yango
Jer Yango

Reputation: 592

For a UMDF driver, it is possible to use the WdfRequestImpersonate function. This function creates an event callback function that the UMDF could use to impersonate the access rights of the requesting process.

Note that the Impersonation level should be SecurityImpersonation. This needs to be declared in the INF file, as well as supplied in the WdfRequestImpersonate function parameters. OpenProcess can now be called from within the callback function.

Do note that WdfRequestImpersonate will not return until the callback function ends, and that the impersonation is limited to the contents of the callback function only.

Upvotes: 0

Related Questions