---------- Forwarded message ---------- From: Steve French <smfrench@xxxxxxxxx> Date: Wed, Jan 11, 2017 at 11:58 AM Subject: Re: [PATCH] SMB2: Enforce sec= mount option To: Scott Lovenberg <scott.lovenberg@xxxxxxxxx> Cc: Sachin Prabhu <sprabhu@xxxxxxxxxx>, Germano Percossi <germano.percossi@xxxxxxxxxx>, linux-cifs <linux-cifs@xxxxxxxxxxxxxxx> There is a broader question here about signing (making sure we enforce it properly if signing is requested but not supported) but I think that ntlmv2 can map to ntlmssp/ntlmv2. Given that ntlmv2 is the level of password hash used in our implementation of ntlmssp - I am fine with allowing ntlmv2 as a synonym (we wouldn't distinguish gssapi encapsulation of ntlmssp as a distinct sec version either - what matters is the level of security). On the question of signing: 1) if the server requires signing we turn it on (without signing required on the client mount, we allow the server to choose) 2) if the client requires signing and the server doesn't support it we should fail since the client expects signing I wouldn't mind adding mount option that forces signing to be off no matter what the server requested but doubt it would be needed. I do agree about accepting a list of sec= options and would take a kernel patch for that, but our earlier decision was that this could be done easier in user space (mount.cifs) - ie retry with different sec= options if the user specified more than. On Wed, Jan 11, 2017 at 11:48 AM, Scott Lovenberg <scott.lovenberg@xxxxxxxxx> wrote: > > On Wed, Jan 11, 2017 at 6:17 AM, Sachin Prabhu <sprabhu@xxxxxxxxxx> wrote: > [snip] > > My own opinion is that when a mount option is explicitly passed, it is > > expected the option provided be used and fail if it cannot be used. I > > think replacing a explicitly requested mount option with another can > > lead to unexpected results and may also affect things activities like > > testing. > > > > There are other mount options like "vers=" where cifs doesn't attempt > > to replace an invalid protocol version with another. This in my opinion > > is the correct behaviour. > > Allow me to play Devil's advocate, but with a bridge we'll have to > cross if we enact this behavior... Quoth The (current-ish) Fine Manual > page for mount.cifs (quoted in full for historical mail list > reference) : > " > sec= > Security mode. Allowed values are: > > · none - attempt to connection as a null user (no name) > · krb5 - Use Kerberos version 5 authentication > · krb5i - Use Kerberos authentication and forcibly enable > packet signing > · ntlm - Use NTLM password hashing > · ntlmi - Use NTLM password hashing and force packet signing > · ntlmv2 - Use NTLMv2 password hashing > · ntlmv2i - Use NTLMv2 password hashing and force packet signing > · ntlmssp - Use NTLMv2 password hashing encapsulated in > Raw NTLMSSP message > · ntlmsspi - Use NTLMv2 password hashing encapsulated in > Raw NTLMSSP message, and force packet signing > The default in mainline kernel versions prior to v3.8 was > sec=ntlm. In v3.8, the default was changed to sec=ntlmssp. > > If the server requires signing during protocol negotiation, > then it may be enabled automatically. Packet signing may also be > enabled > automatically if it's enabled in /proc/fs/cifs/SecurityFlags. > " > > What is the defined behavior if I specify that I'd like any of the > more current NTLM variants kerberos-5, explicitly, without packet > signing but the server requires packet signing? Currently, we > silently turn it on. Is the defined behavior to now loudly fail > rather than enable signing? Especially since the default value > changed in Linux-3.8. I'd argue that we already somewhat treat the > "sec" option as a preference rather than a requirement. I would > further argue, although not strongly, that if we want to go down this > road, that we should accept multiple options and if NONE of them can > be used, then we fail. Does anyone have a better idea, or is the > consensus that this isn't as large of an issue (both technologically > and from a user perspective) as I perceive it to be? > > Steve, I'll defer to you as well with my objection above noted. -- Thanks, Steve -- Thanks, Steve -- 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
