Having two names is not necessarily better than one, part 2

  • Article

Previously I wrote about what happens when there are 2 devices in a stack with a name and all of the associated issues that arise from it.  In that vein I want to write about what happens when you give your device object a name in KMDF and compare it to WDM. 

In a WDM driver, if you specify a name for your device object when you call IoCreateDevice nothing related to security descriptors occurs.  The device is accessible to everything on the machine.  On a side not, if you specify certain types of DeviceTypes a different security descriptor will be applied to your device and it will limit who can open your device.

On the hand, when you assign a name to the device in a KMDF driver (by calling WdfDeviceAssignName), KMDF will either use an SDDL string you provide, or if one is not provided, a different security descriptor other than the WDM default.  As opposed to the WDM default which allowed anyone to open the device, the KMDF default specifies that only administrators can open the device using the SDDL string "D:P(A;;GA;;;SY)(A;;GA;;;BA)" (which is defined as the constant SDDL_DEVOBJ_SYS_ALL_ADM_ALL in wdmsec.h).  If you don't like this default you can specify your own SDDL when creating the device by calling WdfDeviceInitAssignSDDLString.  If you want the WDM default, I think that SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX (see wdmsec.h) will give you what you want.

This behavior is documented in the online help, you can read it here.  There is also a good page on SDDL for device objects.

So why did we do this?  This is obviously a breaking change from WDM behavior and it does make writing or porting to a KMDF a little harder because you will probably encounter this issue only after you execute your application as a non administrator and see that it cannot open your device.  Well, we had good reason:  we wanted a KMDF driver to be secure by default  and to have access open up explicitly unlike the WDM model where you could open yourself up to anyone and had to explicitly restrict access.  By making access explicit you have to think about who should access the device as a part of the creation of the driver.  Being explicit about access is pervasive through other types of device object creation as well, both raw PDOs (WdfPdoInitAssignRawDevice) and control devices (WdfControlDeviceInitAllocate) require an SDDL string to be created.