views:

349

answers:

1

I'm trying to lock down a registry key with some important information that must be accessible at the client machine, I do not wan't non-administrators to have access to this key. If you are an admin you'll already be able to do more damage than what I'm storing in the key.

What I'm currently looking to do is this:

//Allow access only to administrators and deny all rights to everyone else.
System.Security.AccessControl.RegistrySecurity acl = 
new System.Security.AccessControl.RegistrySecurity();
acl.AddAccessRule(
    new System.Security.AccessControl.RegistryAccessRule(
        "Administrators", 
        System.Security.AccessControl.RegistryRights.FullControl, 
        System.Security.AccessControl.AccessControlType.Allow));

acl.AddAccessRule(
    new System.Security.AccessControl.RegistryAccessRule(
        "Everyone",
        System.Security.AccessControl.RegistryRights.FullControl,
        System.Security.AccessControl.AccessControlType.Deny));

//Prevent inherited read access from the software or company key allowing access.
acl.SetAccessRuleProtection(true, false);

MyKey.SetAccessControl(acl);

If I have it right this will deny access to everyone, allow access explicitly to anyone in the administrators group and will prevent all inherited permissions from applying to my key? I'd rather find out if it will work before I screw up the ACL on the key such that I can't delete it etc. Should I set the owner of the key to be the administrators group as well?

PS: It's very important that the key cannot even be read as a non administrator, not just changed.

+1  A: 

Be very careful with deny rules - they're only rarely necessary.

If the only ACE in the ACL is for administrators giving them the access you want them to have, then no one else will have access to the key since there's no ACE granting them access.

It's unclear to me from the documentation for AddAccessRule() if it'll guarantee that a new rule (or ACE) will be added to the end of the ACL or not. This is likely to be the case, but if it's happens to not work that way and your deny ACE ends up before the ACE granting access to Admins, then the deny ACE will 'override' the one granting access (the first system stops looking at the ACL once it hits the first ACE that grants or denies permission). This is why using deny ACE's can be tricky. And since an ACL that doesn't explicitly grant permission causes the access check to fail, you generally only need to specify who is permitted access.

You will likely want to ensure that the owner is set to the admin group - an owner can have no access to a key (or whatever object), but an owner always has the right to change the ACL (makes sense if you think about it for a moment).

Michael Burr
So the Deny rules are more to deal with propagated permissions. My intention is to new the ACL, add the one rule I want and then set the ACL directly this way. (as opposed to get ACL, change, apply). Do you know if there are any special system accounts that must have access to the key?
Spence
Whether any special system accounts need access to the key depends on what the key is and what it's used for. For example, if any services need access to the key, then whatever account the service runs under (or group that account is in) will need access.
Michael Burr
The one I'm worried about is "LocalSystem". If I remove that would it be bad...
Spence
You should test it - I think there wouldn't be a problem removing LocalSystem unless the key needs to be accessed by a service that's running under the SYSTEM account. If it's a key that you've created for your own purposes (not something that Microsoft uses for some configuration item or whatever), there shouldn't be a problem. If no Windows system process looks for the key, they won't care that they can't access it. But test it - don't just take my word for it.
Michael Burr
Adding a single allow rule worked a treat. Thanks :)
Spence