icacls silently adds SYNCHRONIZE to DENY ACL and Explorer sometimes asks for that permission

[Richard Sharpe]

On Tue, Apr 9, 2013 at 3:11 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> On Tue, Apr 9, 2013 at 3:05 PM, Jeremy Allison <jra at samba.org> wrote:
>> On Tue, Apr 09, 2013 at 02:16:09PM -0700, Richard Sharpe wrote:
>>> Hi folks,
>>>
>>> I am seeing a weird problem.
>>>
>>> This problem came about because a customer is trying to use icacls to
>>> set a DENY:(D,WDAC) entry on a folder. This succeeds, however, if they
>>> access the folder with Windows Explorer while using SMB2, they get
>>> ACCESS DENIED, but if they access the folder with Windows Explorer
>>> while using SMB1 they do not get ACCESS DENIED.
>>>
>>> the icacls command used was: icacls z:\some-dir /deny SOME-USER:(D,WDAC)
>>>
>>> SYNCHRONIZE always gets added, but icacls refuses to show it.
>>>
>>> The problem seems to be that icacls silently adds SYNCHRONIZE along
>>> with DELETE and WDAC to the DENY entry. Over SMB2, explorer asks for
>>> permissions of 0x00100081 while over SMB1 it only asks for 0x00000081.
>>>
>>> The above is against Samba 3.6.12+. However, even with Win7 accessing
>>> W2K08R2 via SMB where I have added a deny entry as above, I get ACCESS
>>> DENIED. I will check SMB1 soon.
>>>
>>> The icacls command used on the W2K08R2 system was: icacls test_dir
>>> /deny SOME-USER:(D,WDAC)
>>>
>>> Has anyone seen this issue before? The only way to avoid getting the
>>> SYNCHRONIZE bit set is to use SDDL it seems (or smbcacls :-)
>>
>> Should we ignore the SYNCHRONIZE bit on access requests ?
>
> I don't think so. There is a report out there from Microsoft that
> icacls is broken in this regard:
>
> https://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/430f61ee-b278-4cfe-8697-f085f9842d00
>
>> Let me have a look at the MS-FSA...
>
> I am testing now to see if W2K08, when accessed via SMB1 gives the
> same behavior.
>
> If so, then I think we should do what Windows does. Especially since a
> combination of PowerShell scripting and SDDL will do what the customer
> wants to do, I believe (PS Scripting to get the SID for a user.)

I should have said that I went to MS-DTYP to check the handling of the
SYNCHRONIZE bit in ACCESS_CHECK but there were no exceptions.

I also believe that I now have demonstrated that W2K8 behaves in the
same way over SMB1. That is, access succeeds over SMB1 but is denied
over SMB2. This is really strange.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)