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. 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. > > -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
