Specific group permission for a device driver

Hello, I currently have a driver that is restricted to Administrator permissions only. I would like to change this to be restricted to only allow access with membership to a group “FooGroup”. The installer can create FooGroup. And an additional install step would be to add users who should have access to the device driver to FooGroup. I’ve read https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/sddl-for-device-objects?redirectedfrom=MSDN but there doesn’t seem to be a way to restrict access to a particular group name. Does anyone know of a way to do this?

Well, you could put the Protection in your INF.

I can’t recall if you can actually put a specific SID in the SDDL subset supported by IoCreateDeviceSecure. Try it and see.

Peter

This looks similar to this thread [ https://community.osr.com/discussion/293189/what-is-the-standard-solution-to-only-allow-a-certain-service-to-send-ioctls-to-a-device-object#latest ] a week or so ago … and trys to solve the same problem, “how do I prevent anyone but someone I trust from accessing my driver IOCTL”

I’ve seen a number of ways to do this … some folks get the calling process path from the PID in the FileCreate handler and check it’s signature all the way up the cert chain … if it doesn’t pass then the call fails and the caller doesn’t get a handle. The problem with this is that most malware attaches to a process thread and grabs the resources of that process (including your nice vetted file handle), that’s called “privilege escalation”. It also doesn’t check any loaded DLL’s, which means you’ve got a nice retinal scanner on the front door but the side doors, windows and pet door are free to the wind

Other people I’ve seen let the OS do the checking by creating custom user groups (think “backup group”) and using either the .inf file or IoCreateDeviceSecure to only let those group in. The problem with this, other than the installer nightmare trying to create these custom groups and get a particular user assigned to it (and sometimes do this on a domain) is that again, once malware gets into your vetted application you’re finished (but it does fix the DLL issue)

Fundamentally it’s really not the access you want to vette, it’s the data coming into the driver that you want to vette … and that’s where most high security “hostile environment” drivers put the energy (think laptops deployed with soldiers in a war zone, or agencies with classified networks). They assume that the client has been compromised and use the equivalent of TLS encryption between the two … there are good writeups about this, google “data in motion” …

I can’t recall if you can actually put a specific SID in the SDDL subset supported by IoCreateDeviceSecure. Try it and see.

The problem with that proposal is that it is very difficult for a driver to learn the SID associated with a named group. Windows security is mostly a user-mode thing. When I read the question, I thought about having a user-mode helper that maps the name to a SID and passes it to the driver, but how do you get the information in there? I suppose you could store it in the registry.

I can’t recall if you can actually put a specific SID in the SDDL subset supported by IoCreateDeviceSecure. Try it and see.

The problem with that proposal is that it is very difficult for a driver to learn the SID associated with a named group. Windows security is mostly a user-mode thing. When I read the question, I thought about having a user-mode helper that maps the name to a SID and passes it to the driver, but how do you get the information in there? I suppose you could store it in the registry.

Let’s assume my installer will create the group and obtain the SID for the group. The INF file cannot be modified because it is signed along with the driver package at build time. If there is a registry key that can be modified by the installer to insert the new group SID into permissions required to open the driver - that sounds like a promising solution. Any help with details on how to make that happen would be greatly appreciated!

There are a number of places in the registry where you can shove information for the driver. The software key (HKEY\System\CurrentControlSet\Services<yourservice>\Parameters) is an easy one. That path is handed to you in the seldom-used second parameter passed to DriverEntry.

Having said that, the registry is writable by any user with admin privileges. Only you can judge how much protection you need.

You can set the security string directly on the device node and pnp will apply it the next time the device start. See SetupDiSetDeviceRegistryPropertyW(SPDRP_SECURITY_SDS || SPDRP_SECURITY) or the more modern equivalent, CM_Set_DevNode_PropertyW(DEVPKEY_Device_SecuritySDS || DEVPKEY_Device_Security)

I have to comment on your use of the term “modern”. Those of us who have been around for awhile know that the cfgmgr32 APIs came first, and the SetupDi APIs were essentially built on top of them quite a bit later. In fact, the CM APIs were “deprecated” until the One Core concept came around, where CM was included and SetupDi was not, and their roles were reversed.

The first time I see setupapi.h is in the Windows 2000 SDK, whereas CM_Set_DevNode_Property was part of the Windows 98 DDK.

Because I never throw anything away.

I agree with you, I was playing a little loose with the term modern. I know the history ;). I was the lead for the team when we defined and implemented the rules and installation of DHC(U) driver packages and fully appreciate the monstrosity that setupapi.dll is and why the CM APIs are the path moving forward for every product type outside of desktop.

I will investigate. Thank you both for your help!