Yes that has been the behavior since Windows 2000 and I would not call it a
security hole though it would be for the user that does not understand that
and probably most don't. I don't know why MS decided to implement such
behavior. You comment on if an intruder gains access to the system then all
they need to do... Well they would most likely need and have
system/administrator access to change such permissions and their ability to
do that would be among the least of your worries at such point. Where it
really gets confusing is where you see an inherited deny and an inherited
allow and the allow prevails. This can be the case if the allow permission
is configured "closer" in the path to the object than the deny was. I always
suggest that when possible users should not use deny permissions as lack of
permission is an implicit deny and because of the way permissions
inheritance is applied often users think they have a secure access control
list when they do not. --- Steve
http://technet2.microsoft.com/Window....mspx?mfr=true
Notes
. Inherited Deny permissions do not prevent access to an object if the
object has an explicit Allow permission entry.
. Explicit permissions take precedence over inherited permissions,
even inherited Deny permissions.
"Will" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> The general rule in Windows XP, Windows 2000, and Windows 2003 is that in
> a
> file access control list (i.e., DACL), the deny permissions are scanned
> first, and only after excluding the requestor from the Deny list are the
> Accept list entries scanned. It turns out that the kernel does not have
> this restriction, but the GUI tools we use in Windows XP to set file
> security always place the Deny list entries at the top.
>
> Well, I have made the ugly discovery today on a Windows XP SP2 system that
> if you set a folder to inherit permissions, then attempt to add some
> additional user or group objects into the list, that now those additional
> objects are placed at the *top of the DACL*. If those new access rule
> entries are Accept conditions, then they will be executed *before* the
> Deny
> entries in the inherited list, and your Deny list does NOT get priority
> execution.
>
> At very least, this very surprising behavior is not well documented. But
> here is why I consider this to be a very serious bug. Any intruder who
> manages to get into a system now need only put a duplicate entry into the
> DACL to in effect reverse its meaning. If you started with:
>
> Deny ANONYMOUS All
> Deny Guests All
> Accept Administrators All
> Accept SYSTEM All
>
> The user can simply add a rule such as:
>
> Accept ANONYMOUS All
>
> The fully resolved list in the Advanced view of the DACL will now be:
>
> Accept ANONYMOUS All
> Deny ANONYMOUS All
> Deny Guests All
> Accept Administrators All
> Accept SYSTEM All
>
> And sure enough, the Accept rule at the top will execute prior to the Deny
> rule, and the intruder has now introduced a very subtle back door into the
> system that only the most observant administrator could possibly catch.
> The default view of the DACL would only show one entry for ANONYMOUS and
> you
> would have to select it to see that both Accept and Deny columns were
> checked, and many administrators would wrongly assume that the Deny
> entries
> were going to execute first, when in the special case I have found they
> will
> execute after the Accept entry.
>
> Since most of us use inheritance widely on our file systems, this is not
> an
> obscure case. It is in fact the common case. Can someone explain to
> me
> if this is a "feature" and why it should be so?
>
> --
> Will
>
>
>
Similar Threads
