Re: Kerberized mount.cifs with SMB>1?

[Jurjen Bokma <j.bokma-39IHFo8E5E0@public.gmane.org>]

On 10/20/2014 07:09 PM, Steve French wrote:
> On Mon, Oct 20, 2014 at 11:37 AM, Jurjen Bokma <j.bokma-39IHFo8E5E0@public.gmane.org> wrote:
>> On 10/20/2014 06:24 PM, steve wrote:
>>> On 19/10/14 22:48, Jurjen Bokma wrote:
>>>> On 10/19/2014 10:42 PM, steve wrote:
>>>>> On 19/10/14 22:30, Jurjen Bokma wrote:
>>>>>
>>>>>> So I would very much like to use SMB3 to get to the Windows file
>>>>>> servers. Kerberized SMB1 worked like a charm. Speed/bandwidth is not
>>>>>> really the issue here.
>>>>>>
>>>>> Yeah, of course. Never knew there was any security involved. Worrying.
>>>> Did you ever have SMB3 working Kerberized? If I know it's supposed to
>>>> work, I'll give up less easily.
>>>>
>>> Hi
>>> We have everything default. We'd no idea that smb3 existed until this
>>> thread. Anyway, it doesn't work here either:
>>> CIFS VFS: cifs_mount failed w/return code = -128
>>> I think the Kerberos has worked because that codes means that the ticket
>>> has expired, except it hasn't because removing vers=3.0 mounts fine.
>>> But we don't know if our Samba4 file servers are capable of it anyway. I
>>> think we'd have to change something in smb.conf.
>> Maybe to serve SMB3. Max protocol comes to mind. But editing smb.conf is
>> not likely necessary to merely mount a share I presume? IME mount.cifs +
>> Kerberos will work once krb5.conf and request-key are properly
>> configured, regardless of the smb.conf on the client.
>> I did fiddle a bit with /proc/fs/cifs/* though.
>>
>>> Maybe the devs will look if you bugzilla it?
>> Will try. But first I'll take a look myself, lest I don't know what to ask.
> 
> It is doable, and probably easier since the cleanup/rewrite a year or so ago
> of some of the auth code.
> 
> Note that for cifs dialect (in fs/cifs/cifssmb.c) the negotiate response calls
> decode_negTokenInit to parse the asn1 to figure out if kerberos is
> allowed (see around line 595 and following of fs/cifs/asn1.c) then compare
> with the smb2/smb3 case in which we call decode_neg_token_init
> in line 434 of fs/cifs/smb2pdu.c during the processing of the SMB2/SMB3
> negotiate protocol response.  Note that this is ifdef out (CONFIG_SMB2_ASN1)
> since this function has to be changed to match the new format
> 
> Perhaps simply changing
> 
> decode_neg_token_init(security_blob, blob_length, &server->sec_type)
> to
> decode_negTokenInit(security_blob, length, server);
> 
> would get you through negotiate protocol then the only change needed
> would be to SMB2_sess_setup (see lines 526 and following of fs/cifs/smb2pdu.c)
> to parse the asn1 in a similar way to what we do for cifs dialect
> in fs/cifs/sess.c routine sess_auth_kerberos (see liones 543 and later).
> 
> It shouldn't be too bad to finish up.
> 
> Then once negprot and session setup are working with Kerberos then
> the simple use cases (SMB2 and SMB2.1 with signing disabled) should work
> and then for the other use cases will also have to check if SMB2.1/SMB3 signing
> needs changing for krb5 (don't know, probably not) and if
> smb3_validate_negotiate
> needs any minor changes for the krb5 case.
> 
That was just the sort of intro I needed right now. Don't expect
immediate results from me though. I must cram this in between other tasks.

Thanks!
Jurjen