I’m having a problem with security inheritance and
our FSD.
If you bring up the ‘security’ tab in explorer on
the volume (ie, drive letter), it does not show
the 'Allow inheritable permissions to propagate…"
field. While this may be consistent with NTFS,
what happens is that security attributes end up
not being propagated from parents to children (unlike
NTFS).
In an application (or even in explorer), if you make
a change to the security attributes of a directory (like
deny write permissions), the new Security Descriptor and
DACL are not propagated from the directory to children.
If I loopback mount the volume via CIFS (on the same
machine), the field appears and inheritable security
attributes are propagated as one would expect.
Is there some attribute in the device object or
some other magic field that needs to be set to
tell the Security Reference Monitor (or whatever
component of the system seems to take responsibility
for propagating inheritable security attributes) that
yes, indeed, attributes should be propagated from
parent to child?
Any hints would be sincerely appreciated.
Thanks!
I believe it’s up to you, as the FSD, to make sure that inherited ACEs
are indeed respected in child objects of directories who are assigned
security descriptors containing inherited ACEs. Inherited ACEs are
deemed so by the presence of a flag in the ACE_HEADER. Security
descriptors that should inherit ACEs are also deemed so by the presence
of flags in their control descriptors. (This inheritance model is new
for Win2k, in NT4 propogation was NOT automatic). There’s a lot in the
Platform SDK on this topic, search on “Automatic Propagation of
Inheritable ACEs”.
Peter Lawthers wrote:
I’m having a problem with security inheritance and
our FSD.
If you bring up the ‘security’ tab in explorer on
the volume (ie, drive letter), it does not show
the 'Allow inheritable permissions to propagate…"
field. While this may be consistent with NTFS,
what happens is that security attributes end up
not being propagated from parents to children (unlike
NTFS).
In an application (or even in explorer), if you make
a change to the security attributes of a directory (like
deny write permissions), the new Security Descriptor and
DACL are not propagated from the directory to children.
If I loopback mount the volume via CIFS (on the same
machine), the field appears and inheritable security
attributes are propagated as one would expect.
Is there some attribute in the device object or
some other magic field that needs to be set to
tell the Security Reference Monitor (or whatever
component of the system seems to take responsibility
for propagating inheritable security attributes) that
yes, indeed, attributes should be propagated from
parent to child?
Any hints would be sincerely appreciated.
Thanks!
–
Nick Ryan (MVP for DDK)
I finally figured out what the problem is.
I’ll reply to my own post so maybe someone
else doesn’t fall into the same trap and
spend 3 weeks in the bowels of security.
Now I know what it feels like to be the small
intestine.
SetSecurityInfo() and SetNamedSecurityInfo()
are the Win32 library calls that propagate
inheritable security attributes. They make
repeated query/set security IRP calls to
re-establish the ACL/ACE in the new security
descriptor. (Actually they are using NtQuerySecurityObject
and NtSetSecurityObject to accomplish this.
The updated strace-0.3 utility from
http://razor.bindview.com/tools/desc/strace_readme.html
was an absolute godsend in figuring this out).
However, the routines rely on doing a ‘re-open’ where
they pass in a related file object and a NULL
pathname in the IRP_MJ_CREATE. If you don’t
handle this correctly (like I was), you end up
thinking this maybe is a volume open with bogus
params, fail the call, and security inheritance
silently fails.
Nick Ryan wrote:
I believe it’s up to you, as the FSD, to make sure that inherited ACEs
are indeed respected in child objects of directories who are assigned
security descriptors containing inherited ACEs. Inherited ACEs are
deemed so by the presence of a flag in the ACE_HEADER. Security
descriptors that should inherit ACEs are also deemed so by the presence
of flags in their control descriptors. (This inheritance model is new
for Win2k, in NT4 propogation was NOT automatic). There’s a lot in the
Platform SDK on this topic, search on “Automatic Propagation of
Inheritable ACEs”.
Peter Lawthers wrote:
>
> I’m having a problem with security inheritance and
> our FSD.
>
> If you bring up the ‘security’ tab in explorer on
> the volume (ie, drive letter), it does not show
> the 'Allow inheritable permissions to propagate…"
> field. While this may be consistent with NTFS,
> what happens is that security attributes end up
> not being propagated from parents to children (unlike
> NTFS).
>
> In an application (or even in explorer), if you make
> a change to the security attributes of a directory (like
> deny write permissions), the new Security Descriptor and
> DACL are not propagated from the directory to children.
>
> If I loopback mount the volume via CIFS (on the same
> machine), the field appears and inheritable security
> attributes are propagated as one would expect.
>
> Is there some attribute in the device object or
> some other magic field that needs to be set to
> tell the Security Reference Monitor (or whatever
> component of the system seems to take responsibility
> for propagating inheritable security attributes) that
> yes, indeed, attributes should be propagated from
> parent to child?
>
> Any hints would be sincerely appreciated.
>
> Thanks!
>
>
>
–
Nick Ryan (MVP for DDK)
You are currently subscribed to ntfsd as: xxxxx@adic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks for the update. It’s good to know that Windows does not fob off
the responsibility for propagating inheritable ACEs to the FSD; the
Platform SDK was unclear whether SetNamedSecurityInfo would fixup the
descriptors on all objects in the tree itself or leave it up to NTFS.
Peter Lawthers wrote:
I finally figured out what the problem is.
I’ll reply to my own post so maybe someone
else doesn’t fall into the same trap and
spend 3 weeks in the bowels of security.
Now I know what it feels like to be the small
intestine.
SetSecurityInfo() and SetNamedSecurityInfo()
are the Win32 library calls that propagate
inheritable security attributes. They make
repeated query/set security IRP calls to
re-establish the ACL/ACE in the new security
descriptor. (Actually they are using NtQuerySecurityObject
and NtSetSecurityObject to accomplish this.
The updated strace-0.3 utility from
http://razor.bindview.com/tools/desc/strace_readme.html
was an absolute godsend in figuring this out).
However, the routines rely on doing a ‘re-open’ where
they pass in a related file object and a NULL
pathname in the IRP_MJ_CREATE. If you don’t
handle this correctly (like I was), you end up
thinking this maybe is a volume open with bogus
params, fail the call, and security inheritance
silently fails.
Nick Ryan wrote:
> I believe it’s up to you, as the FSD, to make sure that inherited ACEs
> are indeed respected in child objects of directories who are assigned
> security descriptors containing inherited ACEs. Inherited ACEs are
> deemed so by the presence of a flag in the ACE_HEADER. Security
> descriptors that should inherit ACEs are also deemed so by the presence
> of flags in their control descriptors. (This inheritance model is new
> for Win2k, in NT4 propogation was NOT automatic). There’s a lot in the
> Platform SDK on this topic, search on “Automatic Propagation of
> Inheritable ACEs”.
>
> Peter Lawthers wrote:
>
> >
> > I’m having a problem with security inheritance and
> > our FSD.
> >
> > If you bring up the ‘security’ tab in explorer on
> > the volume (ie, drive letter), it does not show
> > the 'Allow inheritable permissions to propagate…"
> > field. While this may be consistent with NTFS,
> > what happens is that security attributes end up
> > not being propagated from parents to children (unlike
> > NTFS).
> >
> > In an application (or even in explorer), if you make
> > a change to the security attributes of a directory (like
> > deny write permissions), the new Security Descriptor and
> > DACL are not propagated from the directory to children.
> >
> > If I loopback mount the volume via CIFS (on the same
> > machine), the field appears and inheritable security
> > attributes are propagated as one would expect.
> >
> > Is there some attribute in the device object or
> > some other magic field that needs to be set to
> > tell the Security Reference Monitor (or whatever
> > component of the system seems to take responsibility
> > for propagating inheritable security attributes) that
> > yes, indeed, attributes should be propagated from
> > parent to child?
> >
> > Any hints would be sincerely appreciated.
> >
> > Thanks!
> >
> >
> >
>
> –
> Nick Ryan (MVP for DDK)
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@adic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
Nick Ryan (MVP for DDK)
Nick,
It’s good to know that Windows does not fob off
> the responsibility for propagating inheritable
> ACEs to the FSD […]
I actually consider the implementation of SD inheritance a disgrace, a
kluge to make von Neumann spin in his grave. Here are two of the
implications:
-
The behaviour requires application writers to not use published,
documented APIs (SetFileSecurity()), hoping instead that they will call
SetNamedSecurityInfo() or a cousin. From what I see daily, the average
application programmer is hard-pressed to spell his name and would be
puzzled to learn that MFC is not “the” NT^H^HWindows API.
-
Assume that directory DIR1 has a child, DIR2, and that DIR2 is exposed
as the root of share FOO. Setting security on DIR2 in its incarnation as
the root of FOO will fail to inherit permissions, because the client has
no way to go back up the tree, past the root of FOO, to DIR1 in order to
retrieve inheritable ACEs. Result: complete loss of inherited security
information. What a crock.
No, if a file system or the documentation thereof claims to support
security inheritance then it should bloody well implement it.
As an aside, I actually met the guy who designed this abomination, and
it grieves me to have to report that he didn’t even blush for the shame
of it all.
Cheers,
Felix.
It gets worse than that. Try moving a file or directory, that has all
of its inherited ACEs set up correctly, to another directory. Nothing
magically fixes the ACL of the file that got moved, much less fixing an
entire hierarchy of files if you move a directory.
It’s frustrating to see a design that is overall pretty decent (NT
security) with such an obvious complete failure.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Felix Kasza
Sent: Tuesday, September 23, 2003 11:13 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: Security Inheritance
Nick,
It’s good to know that Windows does not fob off
> the responsibility for propagating inheritable
> ACEs to the FSD […]
I actually consider the implementation of SD inheritance a disgrace, a
kluge to make von Neumann spin in his grave. Here are two of the
implications:
-
The behaviour requires application writers to not use published,
documented APIs (SetFileSecurity()), hoping instead that they will call
SetNamedSecurityInfo() or a cousin. From what I see daily, the average
application programmer is hard-pressed to spell his name and would be
puzzled to learn that MFC is not “the” NT^H^HWindows API.
-
Assume that directory DIR1 has a child, DIR2, and that DIR2 is exposed
as the root of share FOO. Setting security on DIR2 in its incarnation as
the root of FOO will fail to inherit permissions, because the client has
no way to go back up the tree, past the root of FOO, to DIR1 in order to
retrieve inheritable ACEs. Result: complete loss of inherited security
information. What a crock.
No, if a file system or the documentation thereof claims to support
security inheritance then it should bloody well implement it.
As an aside, I actually met the guy who designed this abomination, and
it grieves me to have to report that he didn’t even blush for the shame
of it all.
Cheers,
Felix.
You are currently subscribed to ntfsd as: xxxxx@sublinear.org To
unsubscribe send a blank email to xxxxx@lists.osr.com