Granting access to a registry key in HKLM\System\CurrentControlSet\Control\Class

Question

I have some commercial software that is protected by a 3rd party soft license. This week the 3rd party licensing failed and I tracked it down to when it was trying to access this registry key:

HKLM\System\CurrentControlSet\Control\Class\{4D36E97D-E325-11CE-BFC1-08002BE10318}\Properties

When manually checking that key, even as an administrator I don't have permission to view it. From some googling around I believe that I can get access if I ran as a "System" account, and I have seen references to tools that would allow me to do that. (Just ran regedit using Sysinternals' PSExec tool and saw that the Properties key only grants access to SYSTEM)

However I can freely access all the non-Properties keys under {4D36E97D-E325-11CE-BFC1-08002BE10318} EG \0000, \0001, \0002 etc

After a bit of back and forth with tech support from my vendor (and them talking to their licensing vendor), the reply was that the licensing software needs access to the Properties key, and that I need to change the registry permissions in order to grant access.

My confusion/concern is that for every key that is under the Class key, the associated Properties key exhibits the same permissions behavior - IE as an admin I can't access it. Given that my Windows system has been running that way for a long long time without any issues, I do not think that granting access for the sake of one program is the correct thing to be doing.

Now to my questions:

1. What systems/accounts genuinely need access to this Properties key?

2. What issues/problems would I be opening myself up to if I did grant open slather access to this key?

3. I suspect that the licensing software may have initially been able to access this particular key when it was being installed through elevated permissions. Does that seem reasonable?

4. Can anyone point me to MS documentation on the subject?

Answer 1

The Properties subkey's owner is usually SYSTEM, but sometimes Administrators. Its contents are used for hardware device management by the kernel. The correct (i.e. default) permissions for the key are only Full control for SYSTEM, nothing for anybody else.

Nothing will break if you grant read access to Administrators or even to Users. It's not good that a program should have to look at those data, but there isn't anything sensitive in any of them. In fact, the vast majority of them appear to contain the same thing. However, granting write access there to non-Administrators is a terrible idea. Modifying these keys can break Plug and Play! Administrators can always do anything they want to the machine, but normal users shouldn't be able to change anything that affects anybody else. (Notice how normal users can't write anywhere inside HKEY_LOCAL_MACHINE.) Also, you should be careful to preserve the original owner of each key, and the Full control SYSTEM ACE (access control entry) should always be preserved.

It is possible that the program's installer running with elevated permissions was allowed to look or write in there. If any part (a service, perhaps) was running as SYSTEM, it would have been allowed based on the ACE. The program could also have taken advantage of administrators' ability to enable SeBackupPrivilege or SeRestorePrivilege, which allow it to read anything or write anything, respectively. (Read more about privileges.) Some MSI installers do indeed enable these powerful privileges.

Microsoft has published very little documentation on these keys, but you can read Device Driver Tools and Settings and {Class-GUID}.