Device objects and DACL

Hello. So there are 2 ways to create software based drivers right, the legacy way using sc and a PNP device using devcon.

For the legacy way, using sc create, sc start, etc, works fine and you can start and then sc stop to fully unload the driver. My driver’s Unload is called, and all resources are cleaned up, and driver verifier is happy. However you cannot apply a INF SDDL to restrict opening of the symbolic handle for IOCTLs, as the sc way doesn’t load the INF.
So how could I apply an admin/system level SDDL on this method?

Alternatively we can use devcon install aaa.inf root\aaa to create a root enumerated device without needing hardware. However when I go to unload my driver via devcon remove I get a Windows popup saying the device requires a restart to unload this driver. All I’ve done is change the INF to be devcon compatible, I haven’t added all the minor PNP IRPs yet, but is that required to just remove the driver without needing to restart the driver. My Unload() doesn’t get called (unlike sc stop) hence why I guess the restart is asked for?

The sc way is obviously the simplest if I can just get the DACL applied. Otherwise I can use the devcon way if I can unload without the reboot, any simple software based wdksamples for this concept?

Oh stupid DriverStore. For the past day, every build I’ve done has been instead loading a cached driver from the DriverStore from devcon and only just realized all my attempted tests never even ran. Even devcon dp_delete wouldn’t delete the driver package, had to manually psexec as system to remove my driver packages.

Simply setting IoCreateDeviceSecure() with the SDDL secured the DACL on the device object, preventing standard users from opening handles to the device. Simple.

Since I am essentially the PDO, with no PCI root device below me, I am legitimately allowed to call IoCreateDeviceSecure right.

KMDF supports the legacy and pnp scenario. Why aren’t you using it? Your life will be much simpler. To stop a pnp driver you need to fully support pnp. KMDF gives this to you from the start, wdm requires you start from scratch. > Since I am essentially the PDO, with no PCI root device below me, I am legitimately allowed to call IoCreateDeviceSecure right. It is not clear which scenario you are asking about here. In the legacy driver case, yes it is safe to assign the dacl directly to the device object. In the pnp case, even for a root enumerated device, it is not safe and you should be using the INF to assign it.

every build I’ve done has been instead loading a cached driver from the DriverStore

Let me guess: You’re trying to do a new install each time? Instead of “disable”, then copy new version of driver to whatever installed location is, then “enable”??

Or are you saying that you WERE copying the driver… to \windows\system32\drivers… but the driver was being loaded from the driver store instead? That should have been evident from the INF… no?

I’m trying to see if there’s a lesson for us all to learn here… or if this is just a case of a problem between keyboard and chair.

Peter

@“Peter_Viscarola_(OSR)” said:
Let me guess: You’re trying to do a new install each time? Instead of “disable”, then copy new version of driver to whatever installed location is, then “enable”??

But now drivers loaded into memory cannot be overwritten, their disk files become locked, like UM applications?
Also, there’s some protection by the PnpLockDown directive

But now drivers loaded into memory cannot be overwritten

Maybe. But that’s not where I was going with that. Rather, the most common error is doing a reinstall each time but having the same DriverVer in the INF. In this case, the old binary is used. The installer says, “Ah! Same version I have already! I know how to deal with this!”

Peter