> If your app is a SERVICE, you can secure access to your driver using a Service SID.
Thanks Peter for mentioning virtual service accounts, which are probably not widely understood.
I really like virtual service SIDs/accounts, and they seem poorly documented. I just did a google search on ?msdn virtual service account? and nothing in the first few pages looked very promising. Virtual service accounts are useful to improve system security and it would help if people didn?t have to dig so deep to find documentation about them (hint hint Microsoft doc team).
Virtual service accounts were added in WIndows 7/Server 2008 R2.
If the OP wants to carefully control access between a device and a service, he could set the security of the device to only allow access from the virtual service account, which should restrict access to only the matching service. If system is not added to the device ACL, I believe services running as system will not have access to the device either. This doesn?t prevent someone from replacing the binary for the service with malware, which you could do if you have administrator access, although it does prevent two services from both claiming to be running in the same virtual service account, so you could perhaps detect tampering attempts. A service and driver could exchange some authentication tokens, although it seems like someone with administrator access has access to the service binary, and as a result can potentially find the key/algorithm used for authentication, and fake it. A driver could look at the calling process, find the loaded module, and run it?s own hash f the nodule and check of a digital signature. Malware would not be able to fake the signature on the service binary. It still seems like there are ways one could fake the identity of if the calling process, assuming malware could install a driver, which would only take administrator account access.
The FAQ on virtual service accounts goes something like…
Virtual service account SIDs have a value based on a hash of the service name, so you can pre-calculate what their value will be and use them for setting security in other places. This also means for a specific service name, the SID value is the same across different machines and it means you can set security using the SID before the service is even installed. Normal account SIDs for named accounts are dynamically generated, and change from machine to machine and each time they are created.
On the downside, virtual service accounts don?t show up in any lists of accounts, which means if a GUI components wants to display a list of valid accounts for setting some security, it leaves out service account names. Many parts of the GUI do the right things when explicitly given an account name in the form ?NT Service\someServcieName?. You can also get the system to calculate the stable virtual service account SID for a service name using the command ?sc -showsid aServiceName?.
I believe you can use virtual service SIDs (not sure about using virtual service account names) to set security via an INF SDDL string, which allow full SDDL, but unfortunately you can’t use them for an SDDL string set from driver code, which uses a limited SDDL subset. I?m not sure why you can?t use an explicit SID from a SDDL string in driver code, as I believe it has all the information needed to generate the binary security descriptor.
Also note that virtual service SIDs/accounts, which are machine local, are different than domain managed service accounts which can only be used for one service across the domain, on only one machine.
One of the huge security screw ups on Windows has always been the rampant use of system and administrator accounts for things that don?t need it. Running a service in the default system account gives it access to almost everything, running it in a virtual service account gives it access to almost nothing, which means you need to explicitly make things accessible to the virtual service account. If a service running in a virtual service account is taken over by malware, the damage it can do to the system is vastly less than if the service was running as system.
Jan