[cifs-protocol] [MS-DTYP] canonical ACL sort order Q3 - TrackingID#2405080040008240

Tue May 14 22:32:10 UTC 2024

hi Jeff,

OK, I like the inductive reasoning, but what if the grandparent was not in 
canonical order -- is the grandchild ACE still said to be in canonical form?

In any case, this answers the question well enough -- we just have to trust our 
inheritance.

thanks

Douglas

On 15/05/24 04:36, Jeff McCashland (He/him) wrote:
> Hi Douglas,
> 
> Could you let us know a bit more about how this relates to what you're working on?
> 
> It appears to me that the documentation sufficiently covers your question #3. We 
> document that inherited ACEs must be kept in the order they are inherited. Since 
> each parent orders their explicit ACEs before their inherited ACEs, the ACEs are 
> already in canonical order coming from the parent. The directive to maintain the 
> order in which they were inherited means they need to be kept in the same order 
> coming from the parent. This will preserve the parent/grandparent ordering 
> without needing to identify which ACEs come from the parent and which come from 
> the grandparent.
> 
> Best regards,
> */Jeff M/**/^c /**/Cashland (He/him) /| Senior Escalation Engineer | 
> Microsoft Corporation*
> 
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) 
> Pacific Time (US and Canada)
> 
> Local country phone number found here: 
> _http://support.microsoft.com/globalenglish 
> <http://support.microsoft.com/globalenglish>_ | Extension 1138300
> 
> 
> --------------------------------------------------------------------------------
> *From:* Jeff McCashland (He/him) <jeffm at microsoft.com>
> *Sent:* Wednesday, May 8, 2024 11:11 AM
> *To:* Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
> *Cc:* cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>; Sreekanth 
> Nadendla <srenaden at microsoft.com>
> *Subject:* Re: [MS-DTYP] canonical ACL sort order Q3 - TrackingID#2405080040008240
> Hi Douglas,
> 
> I will research your question and let you know what I find.
> 
> Best regards,*
> /Jeff M/**/^c /**/Cashland (He/him) /| Senior Escalation Engineer | 
> Microsoft Corporation*
> 
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) 
> Pacific Time (US and Canada)
> 
> Local country phone number found here: 
> _http://support.microsoft.com/globalenglish 
> <http://support.microsoft.com/globalenglish>_ | Extension 1138300
> 
> --------------------------------------------------------------------------------
> *From:* Sreekanth Nadendla <srenaden at microsoft.com>
> *Sent:* Wednesday, May 8, 2024 8:51 AM
> *To:* Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
> *Cc:* cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>
> *Subject:* [MS-DTYP] canonical ACL sort order Q3 - TrackingID#2405080040008240
> Dochelp in Bcc
> 
> Hello Douglas, this e-mail thread will be used to track the investigation for 
> the following issue
> 
> *ISSUE:*
> 
> MS-DTYP definition says little about the ordering of DENY and ALLOW ACEs in the 
> inherited sections. In places where canonical
> ACLs are constructed, such as
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2FSecAuthZ%2Forder-of-aces-in-a-dacl&data=05%7C02%7Csrenaden%40microsoft.com%7Cfe0af73840584248d61808dc6ef382d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638507239378695121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CBrpNXxW1LpEgR2JCm5L6R0YLhld1DYAkYC8dFX43LE%3D&reserved=0
> 
>  > The following steps describe the preferred order:
>  >
>  > 1. All explicit ACEs are placed in a group before any inherited ACEs.
>  >
>  > 2. Within the group of explicit ACEs, access-denied ACEs are placed before
>  >    access-allowed ACEs.
>  >
>  > 3. Inherited ACEs are placed in the order in which they are inherited. ACEs
>  >    inherited from the child object's parent come first, then ACEs inherited from
>  >    the grandparent, and so on up the tree of objects.
>  >
>  > 4. For each level of inherited ACEs, access-denied ACEs are placed before
>  >    access-allowed ACEs.
> 
> the inherited ACEs are placed in stripes like of DENY and ALLOW ACEs,
> like tree rings. This is not part of the definition in MS-DTYP, which
> only says "inherited ACEs are placed in the order in which they were
> inherited". *Should it be part of MS-DTYP 2.4.5?*
> 
> Of course, when looking at a DACL in isolation, there is no way of
> knowing where the inherited ACEs were inherited from, so the question is
> kind of moot. Maybe that is why MS-DTYP doesn't want to say much, and
> why the MS-ADTS algorithm just flattens the inheritance, potentially
> changing the outcome (by bringing a grandparent DENY in front of a
> parent ALLOW).
> 
> 
> Regards,
> 
> Sreekanth Nadendla
> 
> Microsoft Windows Open Specifications
> 
> 
> --------------------------------------------------------------------------------
> *From:* Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
> *Sent:* Tuesday, May 7, 2024 8:11 PM
> *To:* Interoperability Documentation Help <dochelp at microsoft.com>; 
> cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>
> *Subject:* [EXTERNAL] [MS-DTYP] canonical ACL sort order
> hi Dochelp.
> 
> I have questions about the definition of the canonical ACL form, to do
> with the status of callback ACEs and the ordering of inherited ACEs.
> 
> MS-DTYP 2.4.5 says:
> 
>  > An ACL is said to be in canonical form if:
>  >
>  >  * All explicit ACEs are placed before inherited ACEs.
>  >
>  >  * Within the explicit ACEs, deny ACEs come before grant ACEs.
>  >
>  >  * Deny ACEs on the object come before deny ACEs on a child or property.
>  >
>  >  * Grant ACEs on the object come before grant ACEs on a child or property.
>  >
>  >  * Inherited ACEs are placed in the order in which they were inherited.
> 
> I think the third and fourth clauses are talking about the OBJECT ACE
> types, saying that e.g. ACCESS_ALLOWED_OBJECT_ACE_TYPE comes after
> ACCESS_ALLOWED_ACE_TYPE. But is it also talking about ACEs with the
> INHERIT_ONLY_ACE flag? Or some other mechanism?
> 
> Logically it would seem that callback ACEs should be placed is a similar
> position to the OBJECT ones.
> 
> Relevantly, MS-ADTS 6.1.3.1 says:
> 
>  > ACE ordering rules apply only to ACLs in canonical form (see [MS-DTYP]
>  > section 2.4.5), and only when the forest functional level is
>  > DS_BEHAVIOR_WIN2003 or above. The following rules are applied, in the
>  > following order:
>  >
>  > 1. Explicit ACEs come before inherited ACEs.
>  >
>  > 2. Deny ACEs come before Allow ACEs.
>  >
>  > 3. Regular ACEs come before object ACEs.
>  >
>  > 4. Within each group, the ACEs are ordered lexicographically (that is, based on
>  >    octet string comparison rules).
>  >
>  > Rules 3 and 4 above are enforced only when the forest functional level is
>  > DS_BEHAVIOR_WIN2003 or above. Otherwise, the order of ACEs within each group
>  > defined by rules 1 and 2 is retained as supplied by the user or replication
>  > partner.
> 
> Point 4 (sorting "lexicographically" via binary comparison), would sort
> the ACE structures primarily by ACE type, followed by flags, followed by
> the type specific members (often the SID is next).
> 
> That would put the DENY ACEs in this order:
> 
>    ACCESS_DENIED_ACE_TYPE (1)
>    ACCESS_DENIED_OBJECT_ACE_TYPE (6)
>    ACCESS_DENIED_CALLBACK_ACE_TYPE (10)
>    ACCESS_DENIED_CALLBACK_OBJECT_ACE_TYPE (12)
> 
> and similarly for the ALLOW ACEs. But by rule 3, we already have put
> "regular" ACEs before object ACEs, so if callback ACEs count as regular,
> we'd end up with
> 
>    ACCESS_DENIED_ACE_TYPE (1)
>    ACCESS_DENIED_CALLBACK_ACE_TYPE (10)
>    ACCESS_DENIED_OBJECT_ACE_TYPE (6)
>    ACCESS_DENIED_CALLBACK_OBJECT_ACE_TYPE (12)
> 
> Are one of these orderings considered to be part of the canonical form?
> 
> Either would be consistent with my understanding of MS-DTYP 2.4.5 with
> respect to plain and object ACEs.
> 
> (As far as I can tell, the ordering within a block of DENY or ALLOW ACEs
> doesn't matter with respect to the eventual outcome, but putting the
> fancy kinds at the back is likely to be more efficient as it might avoid
> the extra work they entail).
> 
> Also I note the MS-DTYP definition says little about the ordering of
> DENY and ALLOW ACEs in the inherited sections. In places where canonical
> ACLs are constructed, such as
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2FSecAuthZ%2Forder-of-aces-in-a-dacl&data=05%7C02%7Csrenaden%40microsoft.com%7Cfe0af73840584248d61808dc6ef382d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638507239378695121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CBrpNXxW1LpEgR2JCm5L6R0YLhld1DYAkYC8dFX43LE%3D&reserved=0 <https://learn.microsoft.com/en-us/windows/win32/SecAuthZ/order-of-aces-in-a-dacl>
> 
>  > The following steps describe the preferred order:
>  >
>  > 1. All explicit ACEs are placed in a group before any inherited ACEs.
>  >
>  > 2. Within the group of explicit ACEs, access-denied ACEs are placed before
>  >    access-allowed ACEs.
>  >
>  > 3. Inherited ACEs are placed in the order in which they are inherited. ACEs
>  >    inherited from the child object's parent come first, then ACEs inherited from
>  >    the grandparent, and so on up the tree of objects.
>  >
>  > 4. For each level of inherited ACEs, access-denied ACEs are placed before
>  >    access-allowed ACEs.
> 
> the inherited ACEs are placed in stripes like of DENY and ALLOW ACEs,
> like tree rings. This is not part of the definition in MS-DTYP, which
> only says "inherited ACEs are placed in the order in which they were
> inherited". Should it be part of MS-DTYP 2.4.5?
> 
> Of course, when looking at a DACL in isolation, there is no way of
> knowing where the inherited ACEs were inherited from, so the question is
> kind of moot. Maybe that is why MS-DTYP doesn't want to say much, and
> why the MS-ADTS algorithm just flattens the inheritance, potentially
> changing the outcome (by bringing a grandparent DENY in front of a
> parent ALLOW).
> 
> I'll note there are a wide range of formulations of canonicity, from
> Microsoft and elsewhere, not all of which can be compatible. For
> example,
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fdotnet%2Fapi%2Fsystem.security.accesscontrol.commonacl%3Fview%3Dnet-8.0&data=05%7C02%7Csrenaden%40microsoft.com%7Cfe0af73840584248d61808dc6ef382d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638507239378701549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=pfebzEmURR5OTZQD%2B1JkZVW1KzYXj%2BmJO%2BVe%2Fvt3Rzc%3D&reserved=0 <https://learn.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.commonacl?view=net-8.0>
> would not sort the ACEs lexicographically, but by SID.
> 
> Do SACLs have a canonical ordering, beyond having explicit ACEs first?
> 
> cheers,
> Douglas