Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Specific group permission for a device driver

dugendugen Member Posts: 3

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?

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • craig_howardcraig_howard Member Posts: 226

    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" ...

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,163

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • dugendugen Member Posts: 3

    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!

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,163
    edited November 12

    There are a number of places in the registry where you can shove information for the driver. The software key (HKEY\System\CurrentControlSet\Services\\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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,666

    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)

    d
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,163

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,666

    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.

    d
  • dugendugen Member Posts: 3

    I will investigate. Thank you both for your help!

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 24 January 2022 Live, Online
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online