[cifs-protocol] Question about MS-DTYP 2.5.3.4 Algorithm for Creating a Security Descriptor

[Edgar Olougouna]

Nadya,

As a result of this investigation, a new note will be added in MS-DTYP Section 2.5.3.4 to explain how inheritance logic is impacted by protected ACLs. Please find below the provisional change that will appear in a future release of the document.

Current MS-DTYP:


       2.5.3.4   Algorithm for Creating a Security Descriptor
      http://msdn.microsoft.com/en-us/library/cc230299(v=PROT.10).aspx


1.      Any ACEs with the INHERITED_ACE bit set are NOT copied to the assigned security descriptor.

2.      If AutoInheritFlags, as specified in section 2.5.3.4.1<http://msdn.microsoft.com/en-us/library/cc230315(v=PROT.10)>, is set to automatically inherit ACEs from the parent (DACL_AUTO_INHERIT or SACL_AUTO_INHERIT), inherited ACEs from the parent are appended after explicit ACEs from the CreatorDescriptor. For further details, see the parameter list for CreateSecurityDescriptor (section 2.5.3.4.1).

MS-DTYP update similar to the following:



2.5.3.4      Algorithm for Creating a Security Descriptor


1.      Any ACEs with the INHERITED_ACE bit set are NOT copied to the assigned security descriptor.

2.      If AutoInheritFlags, as specified in section 2.5.3.4.1<http://msdn.microsoft.com/en-us/library/cc230315(v=PROT.10)>, is set to automatically inherit ACEs from the parent (DACL_AUTO_INHERIT or SACL_AUTO_INHERIT), inherited ACEs from the parent are appended after explicit ACEs from the CreatorDescriptor. For further details, see the parameter list for CreateSecurityDescriptor (section 2.5.3.4.1).

3.      The preceding table describing ACL inheritance logic holds true if the ACL is not protected. If the ACL is protected, all the ACEs from the Explicit ACL are copied into the assigned security descriptor, resetting any ACEs with the INHERITED_ACE bit set as well. The Inheritable ACL is not considered.

Thanks again for helping us improve the MS-DTYP document.

Best regards,
Edgar

From: Edgar Olougouna
Sent: Tuesday, March 08, 2011 4:16 PM
To: 'nivanova at samba.org'; 'cifs-protocol at samba.org'
Subject: RE: Question about MS-DTYP 2.5.3.4 Algorithm for Creating a Security Descriptor

Nadya,

Thanks for reporting this issue to Microsoft. We confirmed that the behavior you observed is expected. A technical document issue was filed to clarify the algorithm for creating a security descriptor when the creator security descriptor supplies a protected DACL and ACEs with INHERITED_ACE.
The product team is working on the details of updating the relevant algorithm either in MS-DTYP or MS-ADTS, whichever is appropriate.
As an informative reference, Chapter 8 of Windows Internals (4th edition, 2004), which provides an overview of the rules for creating security descriptors, can be consulted on this behavior.

Best regards,
Edgar

From: Edgar Olougouna
Sent: Thursday, February 10, 2011 4:25 PM
To: 'nivanova at samba.org'; cifs-protocol at samba.org
Subject: RE: Question about MS-DTYP 2.5.3.4 Algorithm for Creating a Security Descriptor

Nadya,

I am researching this and will update you as soon as I have news.

Regards,
Edgar

From: didrash at gmail.com [mailto:didrash at gmail.com] On Behalf Of Nadezhda Ivanova
Sent: Wednesday, February 09, 2011 8:04 AM
To: Interoperability Documentation Help; cifs-protocol at samba.org
Subject: Question about MS-DTYP 2.5.3.4 Algorithm for Creating a Security Descriptor

Hi,
I have a question regarding  2.5.3.4 Algorithm for Creating a Security Descriptor.

It is said there that any ACEs provided by the user that contain the INHERITED_ACE flag are not included in the final SD assigned to the object, and in the algorithm they are also disregarded. This is indeed the behavior I observed.
I created a group, providing this security descriptor during creation:
"D:(A;ID;WP;;;AU)"
When I read the SD of the object back, it read O:DAG:DUD:AIS:AI(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)
It had no DACL, as expected.

However, when I performed the same test with a very small change, creating the object with this SD - "D:P(A;ID;WP;;;AU)"
The resulted SD is: O:DAG:DUD:PAI(A;;WP;;;AU)S:AI(OU;CIIOIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)(OU;CIIOIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0-a285-00aa003049e2;WD)

So, it turns out that ACEs with INHERITED_ACE flag provided by the user are not ignored if we break the inheritance at that object. I haven't found in the docs where this is specified, however. Is this a desired behavior?

I am testing against win2003R2

Regards,
Nadya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20110321/7db8a1c6/attachment.html>