Registry and DACLs...

NTDEV
1

If someone could tell me what I’m doing wrong here, I’ll be greatful…
I’m trying to deny DELETE access to a registry key for everyone except the
program that has created it. Here’s a test code I’m using:

HKEY hKey;
DWORD dwDisposition;
PSECURITY_DESCRIPTOR psd;
PACL pOldDacl, pNewDacl;

EXPLICIT_ACCESS ea[2];

char szName1 = “EVERYONE”;
char szName2 = “CREATOR OWNER”;

DWORD a;

a = ::RegCreateKeyEx(
HKEY_LOCAL_MACHINE,
“SOFTWARE\Envox\RegTest”,
0,
NULL,
0,
KEY_ALL_ACCESS,
NULL,
&hKey,
&dwDisposition);

a = ::GetSecurityInfo(
hKey,
SE_REGISTRY_KEY,
DACL_SECURITY_INFORMATION,
NULL,
NULL,
&pOldDacl,
NULL,
&psd);

::BuildExplicitAccessWithName(
&ea[0],
szName1,
DELETE,
DENY_ACCESS,
CONTAINER_INHERIT_ACE);

::BuildExplicitAccessWithName(
&ea[1],
szName2,
DELETE,
GRANT_ACCESS,
CONTAINER_INHERIT_ACE);

a = ::SetEntriesInAcl(
2,
ea,
pOldDacl,
&pNewDacl);

a = ::SetSecurityInfo(
hKey,
SE_REGISTRY_KEY,
DACL_SECURITY_INFORMATION,
NULL,
NULL,
pNewDacl,
NULL);

::LocalFree(psd);
::LocalFree(pOldDacl);
::LocalFree(pNewDacl);

a = ::RegCloseKey(hKey);
a = ::RegDeleteKey(HKEY_LOCAL_MACHINE, “SOFTWARE\Envox\RegTest”);

It succeedes in denying delete access to everyone, but it fails to grant it
back to the program (SetSecurityInfo returns a success code, but RegDeleteKey
fails with ACCESS_DENIED)

I also tried using CURRENT_USER as szName2, setting the access rights one by
one, but nothing works…

TIA,

Marko
ICQ: 5990814

Research is what I’m doing when I don’t know what I’m doing.
– Wernher von Braun

2

If I remember correctly:

To deny access, it is sufficient to have an ACL containing no ACEs
that grant the same access. When you add an explicit deny ACE, it
overrides grant ACEs. Deny ACEs should probably be used to create
specific exceptions to broad access grants. It makes for shorter
ACLs than having many individual grant ACEs

You are denying *everyone* delete access, and ‘everyone’ certainly
contains the creator account. Your ‘exception’ is broader than the
actual grant.

Dave Cox
Hewlett-Packard Co.
NSSO/SANS/SMSO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Marko Bozikovic [mailto:xxxxx@envox.com]
Sent: Saturday, December 02, 2000 11:54 AM
To: NT Developers Interest List
Subject: [ntdev] Registry and DACLs…

If someone could tell me what I’m doing wrong here, I’ll be
greatful…
I’m trying to deny DELETE access to a registry key for
everyone except the
program that has created it. Here’s a test code I’m using:

HKEY hKey;
DWORD dwDisposition;
PSECURITY_DESCRIPTOR psd;
PACL pOldDacl, pNewDacl;

EXPLICIT_ACCESS ea[2];

char szName1 = “EVERYONE”;
char szName2 = “CREATOR OWNER”;

DWORD a;

a = ::RegCreateKeyEx(
HKEY_LOCAL_MACHINE,
“SOFTWARE\Envox\RegTest”,
0,
NULL,
0,
KEY_ALL_ACCESS,
NULL,
&hKey,
&dwDisposition);

a = ::GetSecurityInfo(
hKey,
SE_REGISTRY_KEY,
DACL_SECURITY_INFORMATION,
NULL,
NULL,
&pOldDacl,
NULL,
&psd);

::BuildExplicitAccessWithName(
&ea[0],
szName1,
DELETE,
DENY_ACCESS,
CONTAINER_INHERIT_ACE);

::BuildExplicitAccessWithName(
&ea[1],
szName2,
DELETE,
GRANT_ACCESS,
CONTAINER_INHERIT_ACE);

a = ::SetEntriesInAcl(
2,
ea,
pOldDacl,
&pNewDacl);

a = ::SetSecurityInfo(
hKey,
SE_REGISTRY_KEY,
DACL_SECURITY_INFORMATION,
NULL,
NULL,
pNewDacl,
NULL);

::LocalFree(psd);
::LocalFree(pOldDacl);
::LocalFree(pNewDacl);

a = ::RegCloseKey(hKey);
a = ::RegDeleteKey(HKEY_LOCAL_MACHINE, “SOFTWARE\Envox\RegTest”);

It succeedes in denying delete access to everyone, but it
fails to grant it
back to the program (SetSecurityInfo returns a success code,
but RegDeleteKey
fails with ACCESS_DENIED)

I also tried using CURRENT_USER as szName2, setting the
access rights one by
one, but nothing works…

TIA,

Marko
ICQ: 5990814

Research is what I’m doing when I don’t know what I’m doing.
– Wernher von Braun

You are currently subscribed to ntdev as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

3

At 11:18 AM 12/04/2000 -0800, you wrote:

To deny access, it is sufficient to have an ACL containing no ACEs
that grant the same access. When you add an explicit deny ACE, it
overrides grant ACEs.

One extra point: Order is important in ACL’s. The first matching entry takes
precedence. Subsequent matching entries are ignored. So if you want to
explicitly deny access to an individual entity which might be a member of an
allowed group, you must make certain the “deny” entry is earlier in the ACL
than the group “grant”.

From MSDN:



The system examines each ACE in sequence until one of the following events
occurs:

* An access-denied ACE explicitly denies any of the requested access rights
to one of the trustees listed in the thread’s access token.

* One or more access-allowed ACEs for trustees listed in the thread’s access
token explicitly grant all the requested access rights.

* All ACEs have been checked and there is still at least one requested
access right that has not been explicitly allowed, in which case, access is
implicitly denied.

Because the system stops checking ACEs when the requested access is
explicitly granted or denied, the order of ACEs in a DACL is important.

For Windows NT versions 4.0 and earlier, the preferred order of ACEs is
simple: In a DACL, all access-denied ACEs should precede any access-allowed
ACEs. The SetEntriesInAcl function creates a DACL with ACEs in this order.
However, the low-level functions for adding ACEs to a DACL do not enforce
the preferred order. The AddAce function adds ACEs at a specified location
in an ACL. Functions such as AddAccessAllowedAce add an ACE to the end of an
ACL. It is the caller’s responsibility to ensure that the ACEs are added in
the preferred order.

For Windows 2000, the proper order of ACEs is more complicated because of
the introduction of object-specific ACEs and automatic inheritance.

The following describes the



Pay close attention to that last sentence. You’ve got to be really careful
to control the order of the ACE’s to achieve the security you desire.

Hope this helps!

RLH

4

Richard Hartman wrote:

One extra point: Order is important in ACL’s. The first matching entry takes
precedence. Subsequent matching entries are ignored. So if you want to
explicitly deny access to an individual entity which might be a member of an
allowed group, you must make certain the “deny” entry is earlier in the ACL
than the group “grant”.

I am aware of that. That’s why the first ACE I create is “deny DELETE” to
everyone, and second ACE is “allow DELETE” to creator/owner. Besides,
SetEntriesInAcl takes care (or at least it should) of positioning ACEs. Here’s
a snippet from MSDN:



The SetEntriesInAcl function places any new access-denied ACEs at the
beginning of the list of ACEs for the new ACL. It places any new
access-allowed ACEs just before any existing access-allowed ACEs.



I have also tried to create a new ACL (by setting OldAcl param in
SetEntriesInAcl to NULL) with only these two ACEs, but no luck…
–
Marko
ICQ: 5990814

Research is what I’m doing when I don’t know what I’m doing.
– Wernher von Braun

5

“COX,DAVID (HP-Roseville,ex1)” wrote:

If I remember correctly:

To deny access, it is sufficient to have an ACL containing no ACEs
that grant the same access. When you add an explicit deny ACE, it

Hm, I’ve tried that. I created a new ACL with only DELETE access granted to
“CREATOR OWNER”, and assigned it to the key. But anyone could delete the
key…

Marko
ICQ: 5990814

Research is what I’m doing when I don’t know what I’m doing.
– Wernher von Braun

6

After creating and applying an ACL to a key, use RegEdt32.exe to look
at the resulting permissions graphically. You may not be getting what
you expect, using CREATOR OWNER that way. Or inherited security may
be influencing the behavior.

Or, using the GUI, set permissions that have the desired effect, then
write a utility to dump the DACL to see what the GUI has done, so you
know what to mimic.

Dave Cox
Hewlett-Packard Co.
NSSO/SANS/SMSO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Marko Bozikovic [mailto:xxxxx@envox.com]
Sent: Tuesday, December 05, 2000 9:56 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Registry and DACLs…

“COX,DAVID (HP-Roseville,ex1)” wrote:
>
> If I remember correctly:
>
> To deny access, it is sufficient to have an ACL containing no ACEs
> that grant the same access. When you add an explicit deny ACE, it

Hm, I’ve tried that. I created a new ACL with only DELETE
access granted to
“CREATOR OWNER”, and assigned it to the key. But anyone could
delete the
key…

Marko
ICQ: 5990814

Research is what I’m doing when I don’t know what I’m doing.
– Wernher von Braun

You are currently subscribed to ntdev as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)