NTFS Security Question.

[Wiley Coyote - N2K]

I believe I posted this in the WRONG post - oops.

So:

I have set NTFS perms on the Root of my system volume to EVERYONE: Deny
Write. Yet, I can still create folders and files! I've been an SE for a
longggg time and never saw this before. The perms are at the Root, so there
is nothing to inherit.

This acount that I am using is NOT a member of any supernumery group, just
a plain Jane user account. I logged in with admin rights to check the NTFS
perms and all seems to be OK as follows:

System: CHANGE (not FC),
Everyone Read & Exec, List, Read ((Deny Write),
C.O. : nada,
Administrators: Change,
Users: Read & Exec, List, Read (Deny Write)

One of the reasons for this level of security is to prevent certain web
sites from dropping VB apps in the root and other silly things.

Anyway, just curious as to why I can (as an ordinary user) do this.

If anyone know what is happending that would be good.

Thanks.

[Steven L Umbach]

Hmm. You might also check the advanced page for special permissions and
remove the two special permissions for users there for creating folders and
files to see if that makes a difference. It should work just by making sure
users do not have write permissions which is an implicit deny. If you are
testing with a user account that you changed group membership on make sure
you logoff as that user so that the new logon will reflect changes in group
membership.

Steve


"Wiley Coyote - N2K" > wrote in message
...
>I believe I posted this in the WRONG post - oops.
>
> So:
>
> I have set NTFS perms on the Root of my system volume to EVERYONE: Deny
> Write. Yet, I can still create folders and files! I've been an SE for a
> longggg time and never saw this before. The perms are at the Root, so
> there
> is nothing to inherit.
>
> This acount that I am using is NOT a member of any supernumery group,
> just
> a plain Jane user account. I logged in with admin rights to check the NTFS
> perms and all seems to be OK as follows:
>
> System: CHANGE (not FC),
> Everyone Read & Exec, List, Read ((Deny Write),
> C.O. : nada,
> Administrators: Change,
> Users: Read & Exec, List, Read (Deny Write)
>
> One of the reasons for this level of security is to prevent certain web
> sites from dropping VB apps in the root and other silly things.
>
> Anyway, just curious as to why I can (as an ordinary user) do this.
>
> If anyone know what is happending that would be good.
>
> Thanks.
>
>
>

[Wiley Coyote - N2K]

Thanks Steven. The advanced page did it - DOH!!!

Now, I'm still not sure why the "DENY" allowed this? My understanding (and
I've been an SE and MCT for over 20 years) is that DENY means exactly that.

In the NIX world, deny meand DENY as it does in NDS. Hmmm, perhaps I can get
rich off this and explain to the Gates Empire. NOT!

Anyway, I've been all over the web, and chatted with a lof of people. In
fact, I gave perms to a fellow in Boca Raton (whom I've know for years) to
vpn in and he checked. He was quite surprised as well.

Still looking into it, there must be something that I'm missing, but in the
meantime the Advanced Props fixed it.

Again, tx.

Wiley.

Wiley.
"Steven L Umbach" > wrote in message
...
> Hmm. You might also check the advanced page for special permissions and
> remove the two special permissions for users there for creating folders
> and files to see if that makes a difference. It should work just by making
> sure users do not have write permissions which is an implicit deny. If you
> are testing with a user account that you changed group membership on make
> sure you logoff as that user so that the new logon will reflect changes in
> group membership.
>
> Steve
>
>
> "Wiley Coyote - N2K" > wrote in message
> ...
>>I believe I posted this in the WRONG post - oops.
>>
>> So:
>>
>> I have set NTFS perms on the Root of my system volume to EVERYONE: Deny
>> Write. Yet, I can still create folders and files! I've been an SE for a
>> longggg time and never saw this before. The perms are at the Root, so
>> there
>> is nothing to inherit.
>>
>> This acount that I am using is NOT a member of any supernumery group,
>> just
>> a plain Jane user account. I logged in with admin rights to check the
>> NTFS
>> perms and all seems to be OK as follows:
>>
>> System: CHANGE (not FC),
>> Everyone Read & Exec, List, Read ((Deny Write),
>> C.O. : nada,
>> Administrators: Change,
>> Users: Read & Exec, List, Read (Deny Write)
>>
>> One of the reasons for this level of security is to prevent certain web
>> sites from dropping VB apps in the root and other silly things.
>>
>> Anyway, just curious as to why I can (as an ordinary user) do this.
>>
>> If anyone know what is happending that would be good.
>>
>> Thanks.
>>
>>
>>
>
>

[Steven L Umbach]

I was not sure that deleting the special permissions would work but you
confirmed it did. Since Windows 2000 deny NTFS permission does not work
exactly like it did in NT4.0 and before. For example an explicit allow will
override an inherited deny and if an object has both an inherited deny and
allow permission it is possible for the inherited allow to prevail if it was
originally configured "closer" to the object in the chain of folders. I am
not sure why this was changed and it seems to be a little known/documented
fact. I have only seen it mentioned a couple of times in the dozens of books
I have read for MCSE and Windows security. This is one reason why I always
recommend that users try to configure access control lists without any deny
permissions as often the results are not what is expected and could garner a
false sense of security and instead try to configure access control lists so
that lack of permissions is what is used to control access.

Having said that it still does not seem to explain why your explicit deny
permission for the root folder for write did not work. When you apply
permissions to the main security page it applies to folders, subfolders, and
files. However explicit permissions were also applied in special permissions
for subfolders only and this folder and subfolders only. My guess is that
the operating system gives higher priority to the more specific special
permissions than the "general" permissions for folders, subfolders, and
files and therefore the write deny was overridden by the allow for create
files and create folders in special permissions.

Steve

http://technet2.microsoft.com/WindowsServer/en/library/d043701a-5a2e-4001-b659-0c23c90f76f61033.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




"Wiley Coyote - N2K" > wrote in message
...
> Thanks Steven. The advanced page did it - DOH!!!
>
> Now, I'm still not sure why the "DENY" allowed this? My understanding (and
> I've been an SE and MCT for over 20 years) is that DENY means exactly
> that.
>
> In the NIX world, deny meand DENY as it does in NDS. Hmmm, perhaps I can
> get rich off this and explain to the Gates Empire. NOT!
>
> Anyway, I've been all over the web, and chatted with a lof of people. In
> fact, I gave perms to a fellow in Boca Raton (whom I've know for years) to
> vpn in and he checked. He was quite surprised as well.
>
> Still looking into it, there must be something that I'm missing, but in
> the meantime the Advanced Props fixed it.
>
> Again, tx.
>
> Wiley.
>
> Wiley.
> "Steven L Umbach" > wrote in message
> ...
>> Hmm. You might also check the advanced page for special permissions and
>> remove the two special permissions for users there for creating folders
>> and files to see if that makes a difference. It should work just by
>> making sure users do not have write permissions which is an implicit
>> deny. If you are testing with a user account that you changed group
>> membership on make sure you logoff as that user so that the new logon
>> will reflect changes in group membership.
>>
>> Steve
>>
>>
>> "Wiley Coyote - N2K" > wrote in message
>> ...
>>>I believe I posted this in the WRONG post - oops.
>>>
>>> So:
>>>
>>> I have set NTFS perms on the Root of my system volume to EVERYONE: Deny
>>> Write. Yet, I can still create folders and files! I've been an SE for a
>>> longggg time and never saw this before. The perms are at the Root, so
>>> there
>>> is nothing to inherit.
>>>
>>> This acount that I am using is NOT a member of any supernumery group,
>>> just
>>> a plain Jane user account. I logged in with admin rights to check the
>>> NTFS
>>> perms and all seems to be OK as follows:
>>>
>>> System: CHANGE (not FC),
>>> Everyone Read & Exec, List, Read ((Deny Write),
>>> C.O. : nada,
>>> Administrators: Change,
>>> Users: Read & Exec, List, Read (Deny Write)
>>>
>>> One of the reasons for this level of security is to prevent certain web
>>> sites from dropping VB apps in the root and other silly things.
>>>
>>> Anyway, just curious as to why I can (as an ordinary user) do this.
>>>
>>> If anyone know what is happending that would be good.
>>>
>>> Thanks.
>>>
>>>
>>>
>>
>>
>
>

[Wiley Coyote - N2K]

More info.

In talking with some NIX buddies, it became apparent what was missing (OK ,
not done).

A subordinate object (Folder or file) DOES not inherit the PARENT perms (in
the NIX world this is referred to as Dynamic Inheritance). This is called
"Child-Inherit-Parent". For example, if you have a folder that has DENY
WRITE perms, you may still create (i.e. MODIFY, which included create/delete
etc) a subordinate objetc (File/Foder) within that structure. The CHILD
object however, will assume "Nebulous" permissions that refer to the LINK
back to the parent, but not to itself. In other worlds, the CHILD will
inherit itself! Sound strange, but th elink below may help.

As this discussion revolved around the ROOT of my hard disk, there is
nothing to inherit, thereby leaving the Child-Inherit-Parent property
vacant.

The trick is to PROPOGATE to all FILES (not Folders and Files - that would
really mess things up). Even though there are no files in this dir, NT still
sets the perms for the ROOT of the folder (and it's children) to the
appropriate permissions (this is in the MFT Volume Attributes portions of
the MFT).

This link helped: http://www.pcguide.com/ref/hdd/file/ntfs/secAdv-c.html

This makes sense now and is something that I now actually remember from NT
4.0, which forced an ADMIN to EXPLICITLY set permissions on subordinate
objects (not withstanding the fact that the objects are in the ROOT folder,
C:\ etc.)

Thanks for the info and pointing me in the right direction.

Wiley.

"Steven L Umbach" > wrote in message
. ..
>I was not sure that deleting the special permissions would work but you
>confirmed it did. Since Windows 2000 deny NTFS permission does not work
>exactly like it did in NT4.0 and before. For example an explicit allow will
>override an inherited deny and if an object has both an inherited deny and
>allow permission it is possible for the inherited allow to prevail if it
>was originally configured "closer" to the object in the chain of folders.
>I am not sure why this was changed and it seems to be a little
>known/documented fact. I have only seen it mentioned a couple of times in
>the dozens of books I have read for MCSE and Windows security. This is one
>reason why I always recommend that users try to configure access control
>lists without any deny permissions as often the results are not what is
>expected and could garner a false sense of security and instead try to
>configure access control lists so that lack of permissions is what is used
>to control access.
>
> Having said that it still does not seem to explain why your explicit deny
> permission for the root folder for write did not work. When you apply
> permissions to the main security page it applies to folders, subfolders,
> and files. However explicit permissions were also applied in special
> permissions for subfolders only and this folder and subfolders only. My
> guess is that the operating system gives higher priority to the more
> specific special permissions than the "general" permissions for folders,
> subfolders, and files and therefore the write deny was overridden by the
> allow for create files and create folders in special permissions.
>
> Steve
>
> http://technet2.microsoft.com/WindowsServer/en/library/d043701a-5a2e-4001-b659-0c23c90f76f61033.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
>
>
>
>
> "Wiley Coyote - N2K" > wrote in message
> ...
>> Thanks Steven. The advanced page did it - DOH!!!
>>
>> Now, I'm still not sure why the "DENY" allowed this? My understanding
>> (and I've been an SE and MCT for over 20 years) is that DENY means
>> exactly that.
>>
>> In the NIX world, deny meand DENY as it does in NDS. Hmmm, perhaps I can
>> get rich off this and explain to the Gates Empire. NOT!
>>
>> Anyway, I've been all over the web, and chatted with a lof of people. In
>> fact, I gave perms to a fellow in Boca Raton (whom I've know for years)
>> to vpn in and he checked. He was quite surprised as well.
>>
>> Still looking into it, there must be something that I'm missing, but in
>> the meantime the Advanced Props fixed it.
>>
>> Again, tx.
>>
>> Wiley.
>>
>> Wiley.
>> "Steven L Umbach" > wrote in message
>> ...
>>> Hmm. You might also check the advanced page for special permissions and
>>> remove the two special permissions for users there for creating folders
>>> and files to see if that makes a difference. It should work just by
>>> making sure users do not have write permissions which is an implicit
>>> deny. If you are testing with a user account that you changed group
>>> membership on make sure you logoff as that user so that the new logon
>>> will reflect changes in group membership.
>>>
>>> Steve
>>>
>>>
>>> "Wiley Coyote - N2K" > wrote in message
>>> ...
>>>>I believe I posted this in the WRONG post - oops.
>>>>
>>>> So:
>>>>
>>>> I have set NTFS perms on the Root of my system volume to EVERYONE: Deny
>>>> Write. Yet, I can still create folders and files! I've been an SE for a
>>>> longggg time and never saw this before. The perms are at the Root, so
>>>> there
>>>> is nothing to inherit.
>>>>
>>>> This acount that I am using is NOT a member of any supernumery group,
>>>> just
>>>> a plain Jane user account. I logged in with admin rights to check the
>>>> NTFS
>>>> perms and all seems to be OK as follows:
>>>>
>>>> System: CHANGE (not FC),
>>>> Everyone Read & Exec, List, Read ((Deny Write),
>>>> C.O. : nada,
>>>> Administrators: Change,
>>>> Users: Read & Exec, List, Read (Deny Write)
>>>>
>>>> One of the reasons for this level of security is to prevent certain web
>>>> sites from dropping VB apps in the root and other silly things.
>>>>
>>>> Anyway, just curious as to why I can (as an ordinary user) do this.
>>>>
>>>> If anyone know what is happending that would be good.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Ian]

NTFS permissions are fundamentally different from Unix or Netware
permissions, therefore it's not wise to draw too many parallels.

I would be careful about setting Deny permissions (especially to everyone on
the root!) as it's quite possible to lock the Administrator out this way,
and even the usual route of taking ownership might not get you back in if
what you've done denies access to creator/owner. In general, Deny
permissions should only be used in a few special cases where Allow
permissions can't achieve the desired result.

[Wiley Coyote - N2K]

Not drawing a parallel, simply stating the Child-Inherit-Parent issue.

As for setting DENY, this was done on a test machine that we use for things
like this. In this case, expicit/implicit allow was not the goal, we wanted
to see what would happen at the root. More correctly, one of my students was
curious (which lead to the start of the whole thing).

I would never do this in production. None the less, a lesson was learned and
insight gained, so in my humble opinion, it was worth the effort.

Tx

"Ian" > wrote in message
...
> NTFS permissions are fundamentally different from Unix or Netware
> permissions, therefore it's not wise to draw too many parallels.
>
> I would be careful about setting Deny permissions (especially to everyone
> on
> the root!) as it's quite possible to lock the Administrator out this way,
> and even the usual route of taking ownership might not get you back in if
> what you've done denies access to creator/owner. In general, Deny
> permissions should only be used in a few special cases where Allow
> permissions can't achieve the desired result.