Re: NTFS Security Question.

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" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:rPmdnUy3P5N8FnfZnZ2dnUVZ_sydnZ2d@xxxxxxxxxxxxxx
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" <mits_mvp@xxxxxxxx> wrote in message
news:Om$73zZxGHA.4568@xxxxxxxxxxxxxxxxxxxxxxx
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" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:ks-dndyyOoxa6nfZnZ2dnUVZ_oudnZ2d@xxxxxxxxxxxxxx
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" <mits_mvp@xxxxxxxx> wrote in message
news:%23gzxRgWxGHA.2448@xxxxxxxxxxxxxxxxxxxxxxx
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.











.

Relevant Pages

  • Re: Cannot Delete A Public Folder
    ... Permissions with a Deny. ... I don't see send as and Receive as as listed perms on my public folder ... >> Folders. ...
    (microsoft.public.exchange.admin)
  • Re: NTFS Security Question.
    ... I was not sure that deleting the special permissions would work but you ... Since Windows 2000 deny NTFS permission does not work ... originally configured "closer" to the object in the chain of folders. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: NTFS Deny not Working STRANGE
    ... I always thought that a deny killed everything. ... I would rather not be giving these guys direct access to the server but it ... I too am a firm believer in never using deny permissions and just not ... >> I have gone into Advanced and reset permissions on files and folders. ...
    (microsoft.public.windows.server.security)
  • Re: Why does Everyone have Full Control of everthing?
    ... On *MY* XP Pro system at home all files and folders *DO* inherit ... looked the XP system I use at work, and the permissions are set ... My root at work has permissions ...
    (microsoft.public.windowsxp.general)
  • Re: Permissions (Default settings)
    ... you need uncheck "Allow inherittable permissions ... Microsoft CSS Online Newsgroup Support ... new folders inherit the permissions of the parent folder. ...
    (microsoft.public.windows.server.sbs)