proposed cifs.ko authentication overhaul

[Steve French]

My note got truncated - I also strongly support the idea you noted
of allowing multiple security mechanisms to be passed in (and
presumably saved, so when disconnected, we renegotiate
properly).

Also I am open to different ways of saving the administrator controlled,
system wide security settings (it does not have to be a registry, or
an smb.conf-like file) but it is better if they are persistent (unlike
/proc/fs/SecurityFlags which has to be set on every boot if
you want to change the defaults).

I would also prefer that we set security settings differently for SMB3 (higher)
due e.g. to the performance improvements of signing that were noted
in various conference presentations.  I am not convinced that we even
need to allow anything other than ntlmv2 and Kerberos for SMB3.
We don't want to encourage users to use near-useless security
mechanisms.

On Fri, Nov 30, 2012 at 5:45 PM, Steve French <smfrench at gmail.com> wrote:
> Overhauling the authentication code is probably a good idea but
> a couple quick thoughts:
>
> 1) we must have system wide, administrator controllable, security
> defaults (samba does this, and every modern operating system
> probably does this by now) - for the case of cifs
> (and smb2/smb3) the features don't have to match Windows
> but should include at least the following:
>    - the ability to set signing on for all connection attempts
>    - the ability to set either a list of security mechanisms which
>      are acceptable (I recommend that we allow ntlmv2 and
>      kerberos, and allow administrator to enable others if desired)
>     or set a minimum security level (setting it lower e.g. might be
>  allowing
>      ntlm, or plaintext passwords) than recommended (presumably
>      our minimum acceptable is ntlmv2) or higher (Kerberos).
>      Alternatively
>       -
>
> On Fri, Nov 30, 2012 at 8:27 AM, Jeff Layton <jlayton at redhat.com> wrote:
>> Executive Summary:
>> ------------------
>> I want to overhaul the cifs.ko authentication code to handle
>> autonegotiation better. This means a fair bit of user-visible changes,
>> but I think they're mostly for the better. I don't want to do this work
>> unless it's clear that the proposed design is acceptable though.
>>
>> Longer description:
>> -------------------
>> As I mentioned the other day, I'd like to see us overhaul the auth code
>> in cifs.ko. I'm willing to do this work, but my attempt from several
>> years ago was not merged. I'd like to ensure that the overall design
>> is something everyone can live with before I embark upon coding
>> anything.
>>
>> This may be tl;dr for most folks, but please do read it if you think
>> you care about how all of this works, especially if you might end up
>> reviewing this code.
>>
>> Why change anything?
>> --------------------
>> There are several reasons that I think the auth code needs an overhaul:
>>
>> 1/ The current code hamstrings the ability to properly autonegotiate
>> the auth method to use. It currently decides what auth method it's
>> going to use before ever contacting the server. This means that once
>> you figure out that the server doesn't support the authentication that
>> was decided, it's too late.
>>
>> 2/ The SecurityFlags interface is totally unintuitive. It makes zero
>> sense to perpetuate the travesty of the SecurityFlags interface. For
>> one thing, it's global so you have a server that requires plaintext
>> passwords then you're stuck with that for all of the servers you need
>> to talk to.
>>
>> 3/ Passing in multiple sec= options is broken. This can happen if you
>> have a mount set up in /etc/fstab, and then pass extra options to it
>> when mounting. The extra options get appended onto the end of the
>> options string. In that situation, it's reasonable for a user to expect
>> "last one wins", but the sec= option doesn't currently work that way.
>> The secFlg's will get or'ed and you can end up using the first auth
>> method even though you specified a different one on the command line.
>>
>> A proposed design for the user interface
>> ----------------------------------------
>> Here's a number of changes I'd like to make:
>>
>> 1/ Get rid of the SecurityFlags interface altogether, and simply
>> require anyone who wants fine-grained control over the auth method to
>> use specify a sec= option when mounting. If one isn't specified, then
>> the code will be changed to use the a selection algorithm of its
>> choosing (more on that later).
>>
>> 2/ Steve in particular has mentioned that he thinks there needs to be
>> some mechanism to allow the admin to set system-wide security defaults.
>> I don't think that's really necessary if we only allow the code to use
>> authentication methods that we deem secure by default. Since the sec=
>> mount option is only able to be specified by an administrator in the
>> first place, I don't think it makes any sense to require the admin to
>> also set specific module options in order to use a particular auth
>> method.
>>
>> 3/ it may however make sense to allow an admin to require signing, or
>> to enforce the disabling of signing altogether. A tristate module
>> option could be added for that.
>>
>> If #2 isn't acceptable, then I'm willing to compromise. Perhaps we
>> could add a boolean module option "disable weak crypto" or something.
>>
>> Proposed auth selection algorithm
>> ---------------------------------
>> Once we change the code not to decide the auth method before contacting
>> the server, we can allow it to be a lot smarter about picking an auth
>> scheme. The following applies to SMB1, things are simpler with SMB2,
>> but we still will be living with SMB1 for a long, long time to come.
>> Also, it's possible that in the future SMB3+ will introduce new auth
>> schemes and we'll need a better selection mechanism for that than we
>> have today.
>>
>> For SMB1, we'll set the SMBFLG2_EXT_SEC unconditionally in the NegProt
>> request. We can then use the NegProt response to decide what auth
>> method to use. If the server responds with that bit set, we'll try the
>> methods specified in the SPNEGO response, in the specified order. With
>> that change we can even try to use krb5 without requiring that sec=krb5
>> be specified. We can try to upcall first and then fall back onto the
>> next method if we don't get a ticket.
>>
>> If the server responds w/o setting SMBFLG2_EXT_SEC, then we'll try
>> ntlmv2(i). If that fails, we'll give up. Trying anything lower will
>> require that the admin set the sec= mount option.
>>
>> SMB2 support is still pretty crippled and only supports NTLMSSP
>> currently, but eventually we'll need something similar for it to handle
>> krb5 too.
>>
>> Thoughts?
>> --
>> Jeff Layton <jlayton at redhat.com>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Thanks,
>
> Steve



-- 
Thanks,

Steve