6

Updated (at bottom)

I have a UMDF video driver based upon the IddCx sample. I have a command-line test (running 'As Administrator') that calls CreateFile on a video adapter device instance to get a handle to it for IOCTL purposes. The test fails on the CreateFile call with Access Denied

I discovered that if I simply disable and re-enable the adapter in Device Manager, and then re-run the same test, it succeeds. The test will continue to succeed until I restart Windows, or uninstall/reinstall the device.

The test's CreateFile call itself doesn't trigger any calls to my driver (more on that below), so I can't easily debug it from the bottom up.

Toggling the adapter device's enabled state changes SOMETHING such that the exact same CreateFile call succeeds. I decided to trace the CreateFile call until it fails... here's what I've found:

--- User Mode ---
mytest!CreateFile
ntdll!NtCreateFile
--- Kernel Mode ---
nt!IopCreateFile
nt!ObOpenObjectByNameEx
nt!ObpLookupObjectName
nt!IopParseDevice
nt!SeAccessCheck [returns Access Denied]

nt!IopParseDevice calls nt!SeAccessCheck, and when that returns FALSE, nt!IopParseDevice sets last error to Access Denied and returns failure.

Now, here's the interesting part (that I need help with):

The parameters passed into nt!SeAccessCheck are slightly different, depending upon whether I run my test before or after I disable+enable my device. Notably, the provided SecurityDescriptor parameter's SECURITY_DESCRIPTOR_CONTROL member changes:

(after Windows restart or adding new adapter device)
0x9814 (SE_SELF_RELATIVE | SE_SACL_PRESENT | SE_DACL_PRESENT | SE_DACL_PROTECTED | SE_SACL_AUTO_INHERITED)

(after disable/enable adapter)
0x8014 (SE_SELF_RELATIVE | SE_SACL_PRESENT | SE_DACL_PRESENT)

I don't know enough about Windows security to understand what these two flags signify in the larger context. Can anyone shed light on what might be going on?

Update #1:

I've found that this behavior happens with the Windows-driver-samples video\IndirectDisplay example project. The only change was to add a call to WdfDeviceCreateDeviceInterface between WdfDeviceCreate and IddCxDeviceInitialize, and to add a do-nothing EvtIddCxDeviceIoControl callback (just calls WdfRequestComplete with STATUS_INVALID_DEVICE_REQUEST). So, it doesn't seem to have anything to do with my particular driver (unless it's something I'm failing to do...)

Update #2:

This gets curiouser and curiouser...

It turns out that every time I cycle through disbling and then re-enabling the driver, the security descriptor that gets used is toggled (between the above two options).

Scott Smith
  • 3,900
  • 2
  • 31
  • 63
  • Another interesting tidbit. If I sit at a breakpoint for too long in the debugger, the watchdog will assert and mark the device as non-functional (yellow triangle with exclamation point). This is expected behavior. However, when I enable it (to reset it back to working state), the test above fails; going to non-functional and then to enabled doesn't have the same effect as disabling and re-enabling. Only when I then disable/enable _again_ does the test succeed. Maybe that can provide a clue as to what's causing this... – Scott Smith Apr 20 '21 at 11:04
  • 1
    1) I'm not familiar with UMDF drivers (I'm more into WDM ones) and can't say what's exactly happening with your DACL (it seems that `SE_DACL_PROTECTED` is causing your problem). Have you tried to specify a SDDL string in your [`AddReg`](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-addreg-directive) section? (that would be [here in the sample](https://github.com/microsoft/Windows-driver-samples/blob/master/video/IndirectDisplay/IddSampleDriver/IddSampleDriver.inf#L39)). – Neitsa Apr 23 '21 at 09:42
  • 1
    2) For more info see also [Controlling Device Access](https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/controlling-device-access#specifying-device-security-in-an-inf-file). Be wary that the `P` in SDDL refers to `SE_DACL_PROTECTED `. Starts with a permissive SDDL string and try to built upon it. – Neitsa Apr 23 '21 at 09:44
  • @Neitsa - Reading up on ACLs, access tokens, privileges, security descriptors and SIDs. Will try specifying an SDDL string this weekend. Thanks. – Scott Smith Apr 24 '21 at 08:17
  • 1
    @ScottSmith I also hit this issue, have you found a solution? Thanks. – ravin.wang May 28 '23 at 04:26
  • 1
    @ravin.wang - the solution for me was to add SDDL to the .INF for the driver under **[AddReg]**, e.g.: `HKR,, Security, , "D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)"` – Scott Smith Jun 02 '23 at 16:28

0 Answers0