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@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
