proposed cifs.ko authentication overhaul

Sun Dec 2 04:04:56 MST 2012

On Fri, 30 Nov 2012 17:50:11 -0600
Steve French <smfrench at gmail.com> wrote:

> 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).
> 

I believe you may have misunderstood me there. I wasn't suggesting that
we allow people to pass in multiple auth methods to try. I was
suggesting that we could walk down list of auth types returned in a
SPNEGO response and try each method in turn.

In principle you could try to allow people to do specify a list of auth
types to try, but:

1/ There's little value in adding all of that complexity since they can
always reattempt the mount using a different sec= option.

2/ You can't rely on someone passing in multiple sec= options. There's
no way to discern the user's intent from the order of sec= options
passed in. You'd need a different way to specify the list that doesn't
exist today anyway.

So, I don't intend to add that capability initially. Someone would need
to do that after I've done the overhaul.

> 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).
> 

Here's where I'm unclear. Why do you feel this is needed over and above
the sec= mount option? It's already not possible for an unprivileged
user to pass in arbitrary mount options, so how does adding this extra
knob improve the situation? IOW, what's the attack scenario that you're
concerned about here?

As far as making a knob setting persistent...module options that can be
set in modprobe.conf or on the kernel command line are really the best
way.

> 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.
> 

Sure. Each version is going to end up with its own negotiation
"path" anyway. While NTLMSSP and krb5 are what's available now for
SMB2/3, it's hard to know if there might be another auth type added in
later. I intend to engineer this in such a way that we can easily add
support for different auth types in the future without having to
overhaul everything.

> 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
> 
> 
> 

-- 
Jeff Layton <jlayton at redhat.com>