linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"chuck.lever@oracle.com" <chuck.lever@oracle.com>,
	"linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>
Cc: "borisp@nvidia.com" <borisp@nvidia.com>,
	"simo@redhat.com" <simo@redhat.com>,
	"ak@tempesta-tech.com" <ak@tempesta-tech.com>
Subject: Re: [PATCH RFC 00/15] Prototype implementation of RPC-with-TLS
Date: Tue, 19 Apr 2022 03:31:38 +0000	[thread overview]
Message-ID: <962bbdf09f6f446f26ea9b418ddfec60a23aed8d.camel@hammerspace.com> (raw)
In-Reply-To: <165030062272.5246.16956092606399079004.stgit@oracle-102.nfsv4.dev>

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.

> The new mount option enables client administrators to require in-
> transit encryption for their NFS traffic, protecting the weak
> security of AUTH_SYS. An x.509 certificate is not required on the
> client for this protection.

That doesn't really do much to 'protect the weak security of AUTH_SYS'.
It just means that nobody can tamper with our AUTH_SYS credential while
in flight. It is still quite possible for the client to spoof both its
IP address and user/group credentials.

A better recommendation would be to have users select sys=krb5 when
they have the ability to do so. Doing so ensures that both the client
and server are authenticating to one another, while also guaranteeing
RPC message integrity and privacy.

> This prototype has been tested against prototype TLS-capable NFS
> servers. The Linux NFS server itself does not yet have support for
> RPC-with-TLS, but it is planned.
> 
> At a later time, the Linux NFS client will also get support for
> x.509 authentication (for which a certificate will be required on
> the client) and PSK. For this demonstration, only authentication-
> less TLS (encryption-only) is supported.
> 
> ---
> 
> Chuck Lever (15):
>       SUNRPC: Replace dprintk() call site in xs_data_ready
>       SUNRPC: Ignore data_ready callbacks during TLS handshakes
>       SUNRPC: Capture cmsg metadata on client-side receive
>       SUNRPC: Fail faster on bad verifier
>       SUNRPC: Widen rpc_task::tk_flags
>       SUNRPC: Add RPC client support for the RPC_AUTH_TLS
> authentication flavor
>       SUNRPC: Refactor rpc_call_null_helper()
>       SUNRPC: Add RPC_TASK_CORK flag
>       SUNRPC: Add a cl_xprtsec_policy field
>       SUNRPC: Expose TLS policy via the rpc_create() API
>       SUNRPC: Add infrastructure for async RPC_AUTH_TLS probe
>       SUNRPC: Add FSM machinery to handle RPC_AUTH_TLS on reconnect
>       NFS: Replace fs_context-related dprintk() call sites with
> tracepoints
>       NFS: Have struct nfs_client carry a TLS policy field
>       NFS: Add an "xprtsec=" NFS mount option
> 
> 
>  fs/nfs/client.c                 |  22 ++++
>  fs/nfs/fs_context.c             |  70 ++++++++--
>  fs/nfs/internal.h               |   2 +
>  fs/nfs/nfs3client.c             |   1 +
>  fs/nfs/nfs4client.c             |  16 ++-
>  fs/nfs/nfstrace.h               |  77 +++++++++++
>  fs/nfs/super.c                  |  10 ++
>  include/linux/nfs_fs_sb.h       |   7 +-
>  include/linux/sunrpc/auth.h     |   1 +
>  include/linux/sunrpc/clnt.h     |  14 +-
>  include/linux/sunrpc/sched.h    |  36 +++---
>  include/linux/sunrpc/xprt.h     |  14 ++
>  include/linux/sunrpc/xprtsock.h |   2 +
>  include/net/tls.h               |   2 +
>  include/trace/events/sunrpc.h   | 157 ++++++++++++++++++++--
>  net/sunrpc/Makefile             |   2 +-
>  net/sunrpc/auth.c               |   2 +
>  net/sunrpc/auth_tls.c           | 117 +++++++++++++++++
>  net/sunrpc/clnt.c               | 222 +++++++++++++++++++++++++++++-
> --
>  net/sunrpc/debugfs.c            |   2 +-
>  net/sunrpc/xprt.c               |   3 +
>  net/sunrpc/xprtsock.c           | 211 +++++++++++++++++++++++++++++-
>  22 files changed, 920 insertions(+), 70 deletions(-)
>  create mode 100644 net/sunrpc/auth_tls.c
> 
> --
> Chuck Lever
> 

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  parent reply	other threads:[~2022-04-19  3:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18 16:51 [PATCH RFC 00/15] Prototype implementation of RPC-with-TLS Chuck Lever
2022-04-18 16:51 ` [PATCH RFC 01/15] SUNRPC: Replace dprintk() call site in xs_data_ready Chuck Lever
2022-04-18 16:51 ` [PATCH RFC 02/15] SUNRPC: Ignore data_ready callbacks during TLS handshakes Chuck Lever
2022-04-18 16:51 ` [PATCH RFC 03/15] SUNRPC: Capture cmsg metadata on client-side receive Chuck Lever
2022-04-18 16:51 ` [PATCH RFC 04/15] SUNRPC: Fail faster on bad verifier Chuck Lever
2022-04-18 16:51 ` [PATCH RFC 05/15] SUNRPC: Widen rpc_task::tk_flags Chuck Lever
2022-04-18 16:51 ` [PATCH RFC 06/15] SUNRPC: Add RPC client support for the RPC_AUTH_TLS authentication flavor Chuck Lever
2022-04-18 16:51 ` [PATCH RFC 07/15] SUNRPC: Refactor rpc_call_null_helper() Chuck Lever
2022-04-18 16:52 ` [PATCH RFC 08/15] SUNRPC: Add RPC_TASK_CORK flag Chuck Lever
2022-04-19  2:57   ` Trond Myklebust
2022-04-19 18:16     ` Chuck Lever III
2022-04-19 19:04       ` Trond Myklebust
2022-04-19 19:40         ` Chuck Lever III
2022-04-19 22:08           ` Trond Myklebust
2022-04-20  0:34             ` Chuck Lever III
2022-04-18 16:52 ` [PATCH RFC 09/15] SUNRPC: Add a cl_xprtsec_policy field Chuck Lever
2022-04-18 16:52 ` [PATCH RFC 10/15] SUNRPC: Expose TLS policy via the rpc_create() API Chuck Lever
2022-04-18 16:52 ` [PATCH RFC 11/15] SUNRPC: Add infrastructure for async RPC_AUTH_TLS probe Chuck Lever
2022-04-18 16:52 ` [PATCH RFC 12/15] SUNRPC: Add FSM machinery to handle RPC_AUTH_TLS on reconnect Chuck Lever
2022-04-18 16:52 ` [PATCH RFC 13/15] NFS: Replace fs_context-related dprintk() call sites with tracepoints Chuck Lever
2022-04-18 16:52 ` [PATCH RFC 14/15] NFS: Have struct nfs_client carry a TLS policy field Chuck Lever
2022-04-18 16:52 ` [PATCH RFC 15/15] NFS: Add an "xprtsec=" NFS mount option Chuck Lever
2022-04-19  3:31 ` Trond Myklebust [this message]
2022-04-19 16:00   ` [PATCH RFC 00/15] Prototype implementation of RPC-with-TLS Chuck Lever III
2022-04-19 18:48     ` Trond Myklebust
2022-04-19 18:53       ` Chuck Lever III
2022-04-19 20:49         ` Rick Macklem

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=962bbdf09f6f446f26ea9b418ddfec60a23aed8d.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=ak@tempesta-tech.com \
    --cc=borisp@nvidia.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=simo@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).