[cifs-protocol] [MS-DTYP] canonical ACL sort order Q4 - TrackingID#2405080040008294

Tue May 14 22:21:18 UTC 2024

Thanks Jeff.

That is helpful. I am happy to not worry about SACL ordering.

>> Does that help? What problem are you trying to solve?

What I am doing is looking over the code Samba has to ensure an ACL is in 
canonical order (we do it in four places, slightly differently each time).

The main question probably the one called "Q2 - TrackingID#2405080040008193", 
about where callback ACEs go.

I had naively assumed there would be a Windows API function for putting an ACL 
in the correct order which I could use to make test cases. I realise now that is 
impossible without knowing the inheritance tree.

cheers,
Douglas

On 15/05/24 04:43, Jeff McCashland (He/him) wrote:
> Hi Douglas,
> 
> I reviewed the Windows source code where SACLs are processed, and I did not see 
> any indication of a required or preferred order to SACL ACEs. However, I did 
> notice that when we process SACLs, we process the ACEs in this order: Audit, 
> Label (including trust label and filtering), Attribute, then Scope. However, 
> there's no reason to believe the ACEs need to be in this order. Also, I found a 
> couple of notes to the effect that allow/deny has no effect on the ordering of 
> Audit ACEs, and Object ACEs follow non-Object ACEs.
> 
> Does that help? What problem are you trying to solve?
> 
> 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:12 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>; Microsoft Support <supportmail at microsoft.com>
> *Subject:* Re: [MS-DTYP] canonical ACL sort order Q4 - TrackingID#2405080040008294
> 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:54 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 Q4 - TrackingID#2405080040008294
> Dochelp in Bcc
> 
> Hello Douglas, this e-mail thread will be used to track the investigation for 
> the following issue
> 
> *ISSUE:*
> 
> 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
> would not sort the ACEs lexicographically, but by SID.
> 
> *Do SACLs have a canonical ordering, beyond having explicit ACEs first?*
> 
> 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