none
ACL Auto Inheritance Bits RRS feed

  • Question

  • Hi,

    I've been researching and trying to understand ACL auto inheritance and have found something surprising.  I've written smbtorture tests that show that a security descriptor is not quite set as a "bag of bytes", because of the auto inheritance bits.  For example, if you get a DACL, set that DACL and get the DACL again, the two DACLs retrieved will be different from each other.

    I've tracked this down to two bits related to ACL auto inheritance.  The bits are "SE_DACL_AUTO_INHERITED" and "SE_DACL_AUTO_INHERIT_REQ", defined here: http://msdn.microsoft.com/en-us/library/aa394402(VS.85).aspx

    I've found that these 2 bits are responsible for setting the SE_DACL_AUTO_INHERITED bit on the server, but only if both of them are set to true. In the three other cases, the SE_DACL_AUTO_INHERITED bit is set to false.

    I have a few questions about these bits:
    1) Why is the SE_DACL_AUTO_INHERIT_REQ bit necessary?
    2) Is it really necessary to make the SE_DACL_AUTO_INHERITED bit dependent on both bits?
    3) What exactly does the Windows client do with these bits?
    4) Will it be problematic if I have an SMB server which always sets the SE_DACL_AUTO_INHERITED bit to true? What will this cause Windows clients to do (or not do)?

    I've been looking all over for answers to these questions, but have been unable to find anything that goes in to detail.

    Thanks,
    Zack
    Thursday, July 30, 2009 8:43 PM

Answers

  • Hi Zack,

     

    In the following response I refer to the control flags as defined in the [MS-DTYP] 2.4.6 instead of using the MSDN APIs nomenclature.

     

    Please find below the update to SR and DR control flags that will appear in a future release of [MS-DTYP]:

    SI - SACL Auto-Inherited - Set when the SACL was created through inheritance.

    DI - DACL Auto-Inherited - Set when the DACL was created through inheritance.

    SR - Inheritance Required - Set when the SACL is to be computed through inheritance. When both SR and SI are set, the resulting security descriptor should set SI; the SR setting is not preserved.

    DR - DACL Inheritance Required - Set when the DACL is to be computed through inheritance. When both DR and DI are set, the resulting security descriptor should set DI; the DR setting is not preserved.

     

    The computation of security descriptors is normally performed by the object sore. The usage of security descriptors is not restricted to file objects; it also applies to other types of objects such as kernel objects, registry keys, and active directory objects.

     

    Now, let walk through your questions.

     

    1)      Why is the SE_DACL_AUTO_INHERIT_REQ bit necessary?

     

    The DR and SR bits are more intended for a caller who, as part of managing a resource, also does the computation of ACL inheritance.

    One example of this is a call to set the security descriptor via SetNamedSecurityInfo / SetSecurityInfo; if DR and SR bits are set in the security descriptor, then the parent Security descriptor will be consulted and inheritance will be performed.

    If the caller is using SetKernelObjectSecurity / NtSetSecurityObject / SetFileSecurity, then the supplied security descriptor is stamped on the file with no examination of the parent.

     

    2)      Is it really necessary to make the SE_DACL_AUTO_INHERITED bit dependent on both bits?

     

    As explained in the above descriptions, there is a dependency between DR/DI, and SR/SI. When DR is set along with DI, then the resultant security descriptor should be marked DI. When SR is set along with SI, then the resultant security descriptor should be marked SI.

    Also DR and SR flags are not persistent, i.e. they not preserved. A query of the security descriptor will not return those control flags.

     

    3)      What exactly does the Windows client do with these bits?

     

    In windows implementation, the presence of DR/DI or SR/SI bits signal the Run-Time Library routines that the caller wants to mark the resultant ACL as having been auto-inherited.
    When working with files (which have inheritance provided by ntmarta.dll in Windows), the caller does not need to pass the DR and SR bits. The DR and SR bits are more intended for a caller who, as part of managing a resource, also does the computation of ACL inheritance.

     

    4)      Will it be problematic if I have an SMB server which always sets the SE_DACL_AUTO_INHERITED bit to true? What will this cause Windows clients to do (or not do)?

     

    When stamped on the security descriptor of an object, the DI and SI indicate that the DACL and SACL were computed through inheritance. With that said, the SMB server should not always set the DI or SI control flags. In fact, the object store should be responsible for computing the security descriptor.

     

    Best regards,

    Edgar

    Friday, September 4, 2009 10:07 PM
    Moderator

All replies

  • Hi Zack,

     

    I was wondering if you’ve been able to review MS-DTYP sections 2.4.6, 2.5.2.3 and related.

     

    If not,  would suggest you use this document as a starting point to get a more thorough clarification.

     

    If after going through this information you still have some need for clarification, we can work on making sure the document is clear enough.

     

    Also, for further help regarding the API, you can try the following MSDN forums:

     

    http://social.msdn.microsoft.com/Forums/en-US/windowssecurity/threads

     

    http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/threads

     

    http://social.msdn.microsoft.com/Forums/en-US/windowssdk/threads

     

     

     

    Thanks and regards,


    SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team
    Thursday, July 30, 2009 10:30 PM
  • Sebastian,

    I have reviewed MS-DTYP 2.4.6, 2.5.2.3 and related.  Unfortunately, none of these answer my four questions from above.

    I'm not sure those MSDN forums are the right place for my questions either, since my questions are regarding using ACLs over SMB, rather than using Windows APIs.

    I'd appreciate if we could work towards further clarification of the document, regarding the auto inheritance bits. These are the four main questions I'm trying to find an answer for:

    1) Why is the SE_DACL_AUTO_INHERIT_REQ bit necessary?
    2) Is it really necessary to make the SE_DACL_AUTO_INHERITED bit dependent on both bits?
    3) What exactly does the Windows client do with these bits?
    4) Will it be problematic if I have an SMB server which always sets the SE_DACL_AUTO_INHERITED bit to true? What will this cause Windows clients to do (or not do)?

    Thanks,
    Zack
    Wednesday, September 2, 2009 8:07 PM
  • Zack,

       Thanks for your questions.   One of our team members will work on them and respond to you soon.

    Thanks!

    Hongwei Sun -MSFT
    Thursday, September 3, 2009 2:27 PM
  • Great, thanks Hongwei.
    Thursday, September 3, 2009 6:32 PM
  • Hi Zack,

     

    In the following response I refer to the control flags as defined in the [MS-DTYP] 2.4.6 instead of using the MSDN APIs nomenclature.

     

    Please find below the update to SR and DR control flags that will appear in a future release of [MS-DTYP]:

    SI - SACL Auto-Inherited - Set when the SACL was created through inheritance.

    DI - DACL Auto-Inherited - Set when the DACL was created through inheritance.

    SR - Inheritance Required - Set when the SACL is to be computed through inheritance. When both SR and SI are set, the resulting security descriptor should set SI; the SR setting is not preserved.

    DR - DACL Inheritance Required - Set when the DACL is to be computed through inheritance. When both DR and DI are set, the resulting security descriptor should set DI; the DR setting is not preserved.

     

    The computation of security descriptors is normally performed by the object sore. The usage of security descriptors is not restricted to file objects; it also applies to other types of objects such as kernel objects, registry keys, and active directory objects.

     

    Now, let walk through your questions.

     

    1)      Why is the SE_DACL_AUTO_INHERIT_REQ bit necessary?

     

    The DR and SR bits are more intended for a caller who, as part of managing a resource, also does the computation of ACL inheritance.

    One example of this is a call to set the security descriptor via SetNamedSecurityInfo / SetSecurityInfo; if DR and SR bits are set in the security descriptor, then the parent Security descriptor will be consulted and inheritance will be performed.

    If the caller is using SetKernelObjectSecurity / NtSetSecurityObject / SetFileSecurity, then the supplied security descriptor is stamped on the file with no examination of the parent.

     

    2)      Is it really necessary to make the SE_DACL_AUTO_INHERITED bit dependent on both bits?

     

    As explained in the above descriptions, there is a dependency between DR/DI, and SR/SI. When DR is set along with DI, then the resultant security descriptor should be marked DI. When SR is set along with SI, then the resultant security descriptor should be marked SI.

    Also DR and SR flags are not persistent, i.e. they not preserved. A query of the security descriptor will not return those control flags.

     

    3)      What exactly does the Windows client do with these bits?

     

    In windows implementation, the presence of DR/DI or SR/SI bits signal the Run-Time Library routines that the caller wants to mark the resultant ACL as having been auto-inherited.
    When working with files (which have inheritance provided by ntmarta.dll in Windows), the caller does not need to pass the DR and SR bits. The DR and SR bits are more intended for a caller who, as part of managing a resource, also does the computation of ACL inheritance.

     

    4)      Will it be problematic if I have an SMB server which always sets the SE_DACL_AUTO_INHERITED bit to true? What will this cause Windows clients to do (or not do)?

     

    When stamped on the security descriptor of an object, the DI and SI indicate that the DACL and SACL were computed through inheritance. With that said, the SMB server should not always set the DI or SI control flags. In fact, the object store should be responsible for computing the security descriptor.

     

    Best regards,

    Edgar

    Friday, September 4, 2009 10:07 PM
    Moderator