[cifs-protocol] [MS-SMB2] allow read based on FILE_EXECUTE permission [116073114482785]

Fri Aug 12 04:05:32 UTC 2016

Hi Obaid,

I think I understand it now:
- This extra FILE_READ_DATA that's granted due to the FILE_EXECUTE
permission is not visible to the object store
- In normal read/write operations, the object store is not performing
access checks, it's entirely the responsibility of the SMB2 server (put
another way, the SMB2 server has access to lower-level APIs which are
past the security check point), and since in the SMB server's view, the
handle has FILE_READ_DATA access, the read is allowed.
- In ioctl calls, the object store does perform an access check based on
the ioctl code and its view of the file handle, and that check fails.

I'm just trying to grasp the correct model, both for this case and for
future cases.

If any of this is grossly wrong, I'd be happy to be corrected, otherwise
I think my questions are answered.

Thanks again,
Uri.

On 08/12/2016 02:25 AM, Obaid Farooqi wrote:
> Hi Uri:
> Here is why copy chunk is failing if file is opened without read permissions.
> At the kernel level, if the command is an FSCTL, the access is check based on the CtlCode. 
> This blog explains how you can calculate the access mode required for an IOCTL: http://social.technet.microsoft.com/wiki/contents/articles/24653.decoding-io-control-codes-ioctl-fsctl-and-deviceiocodes-with-table-of-known-values.aspx
> 
> 
> At kernel level, the check for read command is done against IRP_MJ_READ whereas the copychunk test for access is done against IRP_MJ_FILE_SYSTEM_CONTROL which is a different test and involves CtrlCode.
> 
> This is the reason you see a discrepancy in behavior although SMB server has allowed the read access when file is opened with execute.
> 
> Please let me know if this does not answer your question.
> Also let me know if you have more questions.
> 
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
> 
> Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at ramagane at Microsoft dot com
> 
> -----Original Message-----
> From: Uri Simchoni [mailto:uri at samba.org] 
> Sent: Thursday, August 11, 2016 2:02 PM
> To: Obaid Farooqi <obaidf at microsoft.com>
> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
> Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission [116073114482785]
> 
> Hi Obaid,
> 
> I (hopefully) did as requested.
> I'd like to thank you for bearing with me on this one, this is much appreciated.
> 
> Thanks,
> Uri.
> 
> On 08/11/2016 09:33 PM, Obaid Farooqi wrote:
>> Hi Uri:
>> You must have received an email about creation of a workspace with credentials to login. Please download the t.cmd file from there and copy it to your Windows SMB server that you are using for this testing and follow the steps below to collect and send me the traces.
>>
>> 1. Open an elevated command prompt and cd to the directory where you copied t.cmd. For illustration I'll assume you copied it in c:\etw directory.
>>
>> 2. cd to c:\etw and execute the following command:
>> 	C:\etw> t.cmd srvon
>> 3. start a network capture
>> 4. reproduce the copychunk error
>> 5. Once done with error reproduction, execute the following command in the same window you opened in step 1.
>> 	C:\etw>t.cmd srvoff
>> The above command will take couple of minutes to run and will create a 
>> file whose name starts with t and has extension .cab 6. stop network capture and save it.
>> 7. upload the cab file and network capture to the work space where you down loaded the t.cmd file and let me know.
>>
>> Regards,
>> Obaid Farooqi
>> Escalation Engineer | Microsoft
>>
>> Exceeding your expectations is my highest priority.  If you would like 
>> to provide feedback on your case you may contact my manager at 
>> ramagane at Microsoft dot com
>>
>> -----Original Message-----
>> From: Uri Simchoni [mailto:uri at samba.org]
>> Sent: Thursday, August 11, 2016 1:35 AM
>> To: Obaid Farooqi <obaidf at microsoft.com>
>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
>> <casemail at microsoft.com>
>> Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission 
>> [116073114482785]
>>
>> Hi Obaid,
>>
>> I'm still confused about the copychunk behavior.
>>
>> Let me reiterate what I understand, and then try to explain what I don't understand.
>>
>> 1. At the time of open, if the desired access included FILE_EXECUTE, then an SMB2 server would add FILE_READ_DATA to the granted access rights - this bit needs to be added to [MS-SMB2].
>>
>> 2. COPYCHUNK: The only two restrictions mentioned about the dest handle are:
>> a. that it must have FILE_READ_DATA access, b. that it must have either FILE_WRITE_DATA or FILE_APPEND_DATA, or both.
>>
>> 3. Combining the two together would imply that if we open the dest handle with FILE_EXECUTE | FILE_WRITE_DATA, then we'll be implicitly granted FILE_READ_DATA, and the copychunk would succeed.
>>
>> 4. Yet (and here's the part I don't understand), when trying the last thing, the copychunk fails with access-denied.
>>
>> You mentioned that there might be other reasons within the object store to reject the copychunk in this case. That's a case where the object store affects the observed behavior, and if at all possible I would like to understand the source of the object store's rejection of the copy, even if it falls outside MS-SMB2 (e.g. maybe it belongs in MS-FSA).
>>
>> I tried to be more prudent this time, and in the attached packet captures, the only difference between the successful copychunk in have_read.pcap and the failed one in no_read.pcap, is that the dest handle in the failed attempt was created without FILE_READ_DATA in the desired access. However, since it did have FILE_EXECUTE, I would expect that internally it would be granted FILE_READ_DATA, and the copy to succeed.
>>
>> Thanks,
>> Uri.
>>
>> On 08/11/2016 12:43 AM, Obaid Farooqi wrote:
>>> Hi Uri:
>>> For object store on Windows, the execute permissions means read 
>>> access is automatic. The execute permission is called "Read&Execute" 
>>> as noted here https://msdn.microsoft.com/en-us/library/bb727008.aspx
>>> The SMB server does extra permission checking as would be done by IO manager if the operation were local. So I can clearly see that the read permission is allowed at the time of create in the code and no additional permissions are asked for at the time of read.
>>>
>>> As  for the copychunk issue, the server is behaving as documented. So from the standpoint of protocol document, there is nothing to do.
>>>
>>> I looked in the code for what you are describing and see that for copy chunk, server checks for write and append permissions for target and return access denied if that condition is not met. So the error, it appears, is bubbling from object store. 
>>> If you want me to investigate further, I'll need some server side traces from you. If yes, then let me know and I'll send you a tool to collect the traces and also create a workspace where you can upload the resultant traces.
>>>
>>> Please let me know if it does not answer your question.
>>> Also please let me know if you have any additional questions.
>>>
>>> Regards,
>>> Obaid Farooqi
>>> Escalation Engineer | Microsoft
>>>
>>> Exceeding your expectations is my highest priority.  If you would 
>>> like to provide feedback on your case you may contact my manager at 
>>> ramagane at Microsoft dot com
>>>
>>> -----Original Message-----
>>> From: Uri Simchoni [mailto:uri at samba.org]
>>> Sent: Thursday, August 4, 2016 3:28 AM
>>> To: Obaid Farooqi <obaidf at microsoft.com>
>>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
>>> <casemail at microsoft.com>
>>> Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission 
>>> [116073114482785]
>>>
>>> Hi Obaid,
>>>
>>> That description implies that FILE_READ_DATA is granted at open time (NOT on read time). To test that, I tested what happens with another operation - COPYCHUNK, and got some confusing results.
>>>
>>> It seems that with COPYCHUNK, having FILE_EXECUTE on the *source* handle would allow the copy, but having FILE_EXECUTE on the *destination* handle (which also requires FILE_READ_DATA right) would not allow the copy.
>>>
>>> See attached (made against Server2012R2) - the first two attempts test the source handle. Both are successful - one with FILE_READ_DATA and one without FILE_READ_DATA but with FILE_EXECUTE. The next two attempts test the dest handle, and the one without FILE_READ_DATA but with FILE_EXECUTE instead - fails.
>>>
>>> Can you please clarify?
>>>
>>> My testing also confirms that SMB1 wouldn't let you do the same - it has read_for_execute bit in the read request for that purpose.
>>>
>>> Thanks,
>>> Uri
>>>
>>> On 08/04/2016 01:13 AM, Obaid Farooqi wrote:
>>>> Hi Uri:
>>>> My research shows that Windows SMB2 Servers (Vista/WS2008 and onwards) add FILE_READ_DATA to Open.GrantedAccess after file is opened and FILE_EXECUTE is granted by the object store.
>>>>
>>>> I did not find a similar pattern in the smb1 source. If you find otherwise, please let us know.
>>>>
>>>> I have filed a bug against MS-SMB2 document to include this behavior.
>>>>
>>>> Please let me know if this does not answer your question.
>>>> Also please let me know if you have any further question(s).
>>>>
>>>> Regards,
>>>> Obaid Farooqi
>>>> Escalation Engineer | Microsoft
>>>>
>>>> Exceeding your expectations is my highest priority.  If you would 
>>>> like to provide feedback on your case you may contact my manager at 
>>>> ramagane at Microsoft dot com
>>>>
>>>> -----Original Message-----
>>>> From: Uri Simchoni [mailto:uri at samba.org]
>>>> Sent: Wednesday, August 3, 2016 6:55 AM
>>>> To: Obaid Farooqi <obaidf at microsoft.com>
>>>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
>>>> <casemail at microsoft.com>
>>>> Subject: Re: [MS-SMB2] allow read based on FILE_EXECUTE permission 
>>>> [116073114482785]
>>>>
>>>> On 08/01/2016 01:41 AM, Obaid Farooqi wrote:
>>>>> Hi Uri:
>>>>> Thanks for contacting Microsoft. I have created a case to track this issue. A member of the open specifications team will be in touch soon.
>>>>>
>>>>> Regards,
>>>>> Obaid Farooqi
>>>>> Escalation Engineer | Microsoft
>>>>>
>>>>> Exceeding your expectations is my highest priority.  If you would 
>>>>> like to provide feedback on your case you may contact my manager at 
>>>>> ramagane at Microsoft dot com
>>>>>
>>>>> -----Original Message-----
>>>>> From: Uri Simchoni [mailto:uri at samba.org]
>>>>> Sent: Sunday, July 31, 2016 12:45 PM
>>>>> To: Interoperability Documentation Help <dochelp at microsoft.com>
>>>>> Cc: cifs-protocol at lists.samba.org
>>>>> Subject: [MS-SMB2] allow read based on FILE_EXECUTE permission
>>>>>
>>>>> Hi,
>>>>>
>>>>> This question concerns the right to read from a file opened with FILE_EXECUTE but without FILE_READ_DATA in the desired access mask.
>>>>>
>>>>> According to [MS-SMB2] section section 3.3.5.12, about how to process a READ request:
>>>>>
>>>>> If Open.GrantedAccess does not allow for FILE_READ_DATA, the request MUST be failed with STATUS_ACCESS_DENIED.
>>>>>
>>>>> However, testing against Windows Server 2012R2 shows that if 
>>>>> FILE_EXECUTE is granted instead of FILE_READ_DATA, the read is also 
>>>>> allowed (I suppose this has to do with running executables...)
>>>>>
>>>>> The attached tcpdump packet trace demonstrates that - in packet 22, EOF is returned instead of ACCESS_DENIED.
>>>>>
>>>>> Can you please clarify?
>>>>>
>>>>> Thanks,
>>>>> Uri.
>>>>>
>>>>
>>>> The packet capture I originally attached was by (modified) smbtorture command. However the real use case where we see this is when loading a driver from a remote share:
>>>> 1. samba ad member server joined to domain and client joined 2. put a driver file on a share and give everyone full control 3. run the following from elevated command prompt:
>>>> sc create mydriver type=kernel start=demand error=normal 
>>>> binpath=\\my-server.my-domain.local\my-share\mydriver.sys
>>>> sc start mydriver
>>>>
>>>> That would generate the "open for execute and read" pattern.
>>>>
>>>> Thanks,
>>>> Uri.
>>>>
>>>
>>
> 