[PATCH RFC v2 0/5] NFS: isolate mTLS client credentials by network namespace

[Chuck Lever <cel@kernel.org>]

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

This series makes the network namespace the isolation domain. The
RFC thread asked whether the user or mount namespace is the better
binding. tlshd services the handshake socket of one network
namespace, so that is the namespace it already lives in.

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

The keyring is held in struct nfs_net rather than found by name,
because /proc/keys is not namespace scoped. Its serial number
travels with each handshake instead (patches 3-4), and tlshd's
possession of that keyring is what lets a provisioned key grant no
user read permission at all. Both ends of the link exist today, in
tls_handshake_accept() and in tlshd. The handshake genetlink ABI and
the cert_serial= and privkey_serial= mount options do not change.

The keyring is owned by the owner of the network namespace's user
namespace, and grants no permission to anyone else. In a container
with its own user namespace, the container's root can provision the
keyring and its tlshd can link it, while global root on the host
cannot write to it without entering that user namespace. For a
namespace in the initial user namespace the owner is global root,
as before.

Still open is how userspace names the kernel-held keyring. Patch 5
prototypes a request_key type handled in the kernel and tagged
KEY_TYPE_NET_DOMAIN. A keyctl modeled on KEYCTL_GET_PERSISTENT, or a
read-only attribute on the netns-tagged nfs_client sysfs kobject,
would do the same job if the keyrings maintainers prefer one. Keys
that userspace adds are quota-charged by user namespace while the
keyring lives in nfs_net. Confirmation that this is sane when the
two boundaries differ would be welcome.

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

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

---
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: aa98230e410f0ed212b6788c46b1e4d49e0ff7ca
change-id: 20260917-nfs-mtls-identity-04c14f6f348d

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