[cifs-protocol] [MS-DTYP] canonical ACL sort order Q1 - TrackingID#2405080040008125
Douglas Bagnall
douglas.bagnall at catalyst.net.nz
Thu May 16 22:29:36 UTC 2024
I wrote:
> Just to clarify, for the INHERIT_ONLY_ACE flag, are you saying it would go like
> this:
Though since it doesn't really from the point of view of doing access checks on
this ACL, I think this and your "Q2 - TrackingID#2405080040008193" answer are
sufficient to resolve this thread.
Thanks again.
Douglas
>
> explicit ACCESS_DENIED
> explicit ACCESS_ALLOWED
> explicit ACCESS_DENIED with INHERIT_ONLY_ACE flag
> explicit ACCESS_ALLOWED with INHERIT_ONLY_ACE flag
> inherited ACCESS_DENIED
> [...]
>
>
> or like this
>
> explicit ACCESS_DENIED
> explicit ACCESS_DENIED with INHERIT_ONLY_ACE flag
> explicit ACCESS_ALLOWED
> explicit ACCESS_ALLOWED with INHERIT_ONLY_ACE flag
> inherited ACCESS_DENIED
> [...]
>
>
> cheers,
> Douglas
>
> On 16/05/24 05:02, Sreekanth Nadendla wrote:
>> Hello Douglas,
>> Your understanding about the third, fourth clauses, and the logical ordering
>> is correct. Also, an ACE that has INHERIT_ONLY_ACE flag set is typically used
>> for fine grain access control and canonical ordering places them after
>> explicit deny, grant lists.
>>
>>
>> Regards,
>>
>> Sreekanth Nadendla
>>
>> Microsoft Windows Open Specifications
>>
>>
>> --------------------------------------------------------------------------------
>> *From:* Sreekanth Nadendla <srenaden at microsoft.com>
>> *Sent:* Wednesday, May 8, 2024 11:41 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 Q1 - TrackingID#2405080040008125
>> Dochelp in Bcc
>>
>> Hello Douglas, this e-mail thread will be used to track the investigation for
>> the following issue
>>
>> *ISSUE:*
>>
>> 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.
>>
>>
>> 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
>
>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
More information about the cifs-protocol
mailing list