I have come across a case where an application seems to be apply an inheritable OBJECT ALLOW ACE to a directory/container. When that ACE is inherited, it gets broken and Windows does not like any such SD that is retrieved. Attached are two capture showing the inheritable ACE being applied and the result being retrieved.
Created attachment 8798 [details] A two packet capture showing the inheitable Object ACE
Created attachment 8799 [details] A two packet capture showing the result after inheritance
The problem is in se_create_child_secdesc and init_sec_ace, I believe. In se_create_child_secdesc we do: init_sec_ace(new_ace, ptrustee, ace->type, ace->access_mask, new_flags | (set_inherited_flags ? SEC_ACE_FLAG_INHERITED_ACE : 0)); however, there is no way to pass in the object container if one exists in the ACE. Attached is a patch that touches lots of files that might be a solution for this. It is against 3.5.x so it will likely not apply to 4.0 or Master but might apply against 3.6.x. I have not yet tested it because I don't have a torture test to set this up. I am waiting for my contact to test the patch I supplied.
Created attachment 8800 [details] A possible fix for this problem
There might also be an additional issue here: Perhaps I am mistaken, but my reading of the following from librpc/idl/security.idl: typedef struct { security_ace_object_flags flags; [switch_is(flags & SEC_ACE_OBJECT_TYPE_PRESENT)] security_ace_object_type type; [switch_is(flags & SEC_ACE_INHERITED_OBJECT_TYPE_PRESENT)] security_ace_object_inherited_type inherited_type; } security_ace_object; suggests that the secuity_ace_object_type and security_ace_object_inherited_type GUIDS will only be marshalled/unmarshalled if the appropriate bits are set. However, my reading of [MS-DTYP].PDF, section 2.4.4.3 suggest that those fields are present on the wire regardless of the bit values and the flags field only serves to tell us whether those fields are valid.
OK, I have a capture that shows that on-the-wire a GUID in an object ACE that is not valid is not there either. Do, the IDL is correct. Secondly, I have reproduced this against Samba 3.6.12. Here is what a DOS prompt shows: Z:\testagain>icacls file.txt file.txt: The specified server cannot perform the requested operation. Successfully processed 0 files; Failed processing 1 files I will attach a capture showing the SD being set on the parent directory.
Created attachment 8808 [details] Showing setting the Obj Allow ACE and creation and bad SD. This shows setting the SD with an Obj Inherit ACE, followed by creation of a file and then retrieving the SD. Windows does not like the SD that was created on inheritance.
The DACL was created with this SDDL: D:(A;;FA;;;LA)(OA;OICIID;CR;00000000-0000-0000-0000-000000000000;;WD)(A;OICIID;FA;;;BA)(A;OICIID;0x1200a9;;;WD)(A;OICIID;FA;;;CO) However, icacls will not add that DACL to a file. You have to do it with a program that converts that SDDL to a DACL and then writes it directly to the file. My contact gave me such a program.
(In reply to comment #8) > The DACL was created with this SDDL: > > D:(A;;FA;;;LA)(OA;OICIID;CR;00000000-0000-0000-0000-000000000000;;WD)(A;OICIID;FA;;;BA)(A;OICIID;0x1200a9;;;WD)(A;OICIID;FA;;;CO) > > However, icacls will not add that DACL to a file. > > You have to do it with a program that converts that SDDL to a DACL and then > writes it directly to the file. > > My contact gave me such a program. Does a windows server allows such a DACL? I thought only the SMB server would only allow SECURITY_ACL_REVISION_NT4 ACLs which don't allow object allow aces.
(In reply to comment #9) > (In reply to comment #8) > > The DACL was created with this SDDL: > > > > D:(A;;FA;;;LA)(OA;OICIID;CR;00000000-0000-0000-0000-000000000000;;WD)(A;OICIID;FA;;;BA)(A;OICIID;0x1200a9;;;WD)(A;OICIID;FA;;;CO) > > > > However, icacls will not add that DACL to a file. > > > > You have to do it with a program that converts that SDDL to a DACL and then > > writes it directly to the file. > > > > My contact gave me such a program. > > Does a windows server allows such a DACL? > I thought only the SMB server would only allow SECURITY_ACL_REVISION_NT4 > ACLs which don't allow object allow aces. That is a good question. I don't know but will test in a day or so. Somehow a Windows client running CommVault set the DACL as I have a capture showing it. I suspect that it was due to an unusual DACL that it found on the folder, though.
Any news on this one?
Assigning to Richard!
ping