netdev - Re: [PATCH RFC 00/15] Prototype implementation of RPC-with-TLS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Apr 2022 18:48:07 +0000
From:   Trond Myklebust <trondmy@...merspace.com>
To:     "chuck.lever@...cle.com" <chuck.lever@...cle.com>
CC:     "linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "simo@...hat.com" <simo@...hat.com>,
        "ak@...pesta-tech.com" <ak@...pesta-tech.com>,
        "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "borisp@...dia.com" <borisp@...dia.com>
Subject: Re: [PATCH RFC 00/15] Prototype implementation of RPC-with-TLS

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@...merspace.com> 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@...merspace.com