> On Apr 19, 2022, at 2:48 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2022-04-19 at 16:00 +0000, Chuck Lever III wrote: >> Hi Trond- >> >> Thanks for the early review! >> >> >>> On Apr 18, 2022, at 11:31 PM, Trond Myklebust >>> <trondmy@xxxxxxxxxxxxxxx> wrote: >>> >>> On Mon, 2022-04-18 at 12:51 -0400, Chuck Lever wrote: >>>> This series implements RPC-with-TLS in the Linux kernel: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/ >>>> >>>> This prototype is based on the previously posted mechanism for >>>> providing a TLS handshake facility to in-kernel TLS consumers. >>>> >>>> For the purpose of demonstration, the Linux NFS client is >>>> modified >>>> to add a new mount option: xprtsec = [ none|auto|tls ] . Updates >>>> to the nfs(5) man page are being developed separately. >>>> >>> >>> I'm fine with having a userspace level 'auto' option if that's a >>> requirement for someone, however I see no reason why we would need >>> to >>> implement that in the kernel. >>> >>> Let's just have a robust mechanism for immediately returning an >>> error >>> if the user supplies a 'tls' option on the client that the server >>> doesn't support, and let the negotiation policy be worked out in >>> userspace by the 'mount.nfs' utility. Otherwise we'll rathole into >>> another twisty maze of policy decisions that generate kernel level >>> CVEs >>> instead of a set of more gentle fixes. >> >> Noted. >> >> However, one of Rick's preferences is that "auto" not use >> transport-layer security unless the server requires it via >> a SECINFO/MNT pseudoflavor, which only the kernel would be >> privy to. I'll have to think about whether we want to make >> that happen. > > That sounds like a terrible protocol hack. TLS is not an authentication > flavour but a transport level protection. Fair enough. We've been discussing this on nfsv4@xxxxxxxx, and it's certainly not written in stone yet. I invite you to join the conversation and share your concerns (and possibly any alternative solutions you might have). > That said, I don't see how this invalidates my argument. When told to > use TLS, the kernel client can still return a mount time error if the > server fails to advertise support through this pseudoflavour and leave > it up to userspace to decide how to deal with that. Sure. I'm just saying I haven't thought it through yet. I don't think it will be a problem to move more (or all) of the transport security policy to mount.nfs. -- Chuck Lever
