Netdev List
 help / color / mirror / Atom feed
From: Chuck Lever <cel@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	 "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	 Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	 Randy Dunlap <rdunlap@infradead.org>,
	 Christian Brauner <brauner@kernel.org>,
	David Howells <dhowells@redhat.com>,
	 Sagi Grimberg <sagi@grimberg.me>,
	Eric Dumazet <edumazet@kernel.org>
Cc: linux-nfs@vger.kernel.org, keyrings@vger.kernel.org,
	 kernel-tls-handshake@lists.linux.dev, netdev@vger.kernel.org,
	 linux-doc@vger.kernel.org, Chuck Lever <cel@kernel.org>
Subject: [PATCH RFC v3 0/5] NFS: isolate mTLS client credentials by network namespace
Date: Tue, 06 Oct 2026 11:24:01 -0400	[thread overview]
Message-ID: <20261006-nfs-mtls-identity-v3-0-58a69fb107cc@kernel.org> (raw)

An xprtsec=mtls mount names its client certificate and private key
by keyring serial number. tlshd reads those keys with its own
credentials. Each key has to grant user read permission, and any
tlshd on the host that learns a serial number can read it.

The RFC thread asked whether the user or mount namespace is a
better binding than the network namespace. tlshd services the
handshake socket of one network namespace, so that is the namespace
tlshd already lives in.

  https://lore.kernel.org/linux-nfs/20260602154740.49861-1-cel@kernel.org/

After this series each network namespace has its own .nfs keyring,
and the keyring's serial number travels with each handshake (patches
3-4). Possessing that keyring lets tlshd read a key that does not
grant user read permission. tls_handshake_accept() and tlshd already
link a keyring named in the handshake. The handshake genetlink ABI
and the cert_serial= and privkey_serial= mount options are not
changed.

The owner of the network namespace's user namespace now owns the
keyring, so global root on the host cannot write to a container's
keyring from outside.

nfstlskey, the provisioning tool that consumes the key type, is in
https://github.com/linux-nfs/ktls-utils/ .

Tested on v7.3-rc4 plus this series, on one Fedora VM as both NFS
client and NFSD, with tlshd from ktls-utils 1.4.0.

---
Changes in v3:
- Rebased on v7.3-rc6
- No reviews received; stripped the "RFC" Subject prefix
- Link to v2: https://patch.msgid.link/20260925-nfs-mtls-identity-v2-0-aa3ad17dd6c8@kernel.org

Changes in v2:
- Write "serial number" rather than "serial" throughout (Randy)
- Give the .nfs keyring to the netns's user_ns owner (sashiko)
- Link to v1: https://patch.msgid.link/20260918-nfs-mtls-identity-v1-0-197e568d78a7@kernel.org

---
Chuck Lever (5):
      NFS: name the init_nfs_fs() error labels
      NFS: allocate the .nfs keyring per network namespace
      SUNRPC: pass a keyring serial number to the TLS handshake
      NFS: name the namespace .nfs keyring in the x509 handshake
      NFS: add a key type that reveals the namespace .nfs keyring serial number

 Documentation/filesystems/nfs/index.rst   |   1 +
 Documentation/filesystems/nfs/keyring.rst |  69 ++++++++++
 fs/nfs/client.c                           |   9 +-
 fs/nfs/fs_context.c                       |   1 +
 fs/nfs/inode.c                            | 211 ++++++++++++++++++++++--------
 fs/nfs/netns.h                            |   9 ++
 fs/nfs/nfs3client.c                       |   1 +
 fs/nfs/nfs4client.c                       |   1 +
 include/linux/sunrpc/xprt.h               |   1 +
 net/sunrpc/xprtsock.c                     |   1 +
 10 files changed, 248 insertions(+), 56 deletions(-)
---
base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a
change-id: 20260917-nfs-mtls-identity-04c14f6f348d

Best regards,
--  
Chuck Lever <cel@kernel.org>


             reply	other threads:[~2026-10-06 15:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-06 15:24 Chuck Lever [this message]
2026-10-06 15:24 ` [PATCH RFC v3 1/5] NFS: name the init_nfs_fs() error labels Chuck Lever

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=20261006-nfs-mtls-identity-v3-0-58a69fb107cc@kernel.org \
    --to=cel@kernel.org \
    --cc=anna@kernel.org \
    --cc=brauner@kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=edumazet@kernel.org \
    --cc=horms@kernel.org \
    --cc=kernel-tls-handshake@lists.linux.dev \
    --cc=keyrings@vger.kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=sagi@grimberg.me \
    --cc=skhan@linuxfoundation.org \
    --cc=trondmy@kernel.org \
    /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