freebsd-dev/sys/fs/nfsserver
Rick Macklem 896516e54a nfscl: Add a new NFSv4.1/4.2 mount option for Kerberized mounts
Without this patch, a Kerberized NFSv4.1/4.2 mount must provide
a Kerberos credential for the client at mount time.  This credential
is typically referred to as a "machine credential".  It can be
created one of two ways:
- The user (usually root) has a valid TGT at the time the mount
  is done and this becomes the machine credential.
  There are two problems with this.
  1 - The user doing the mount must have a valid TGT for a user
      principal at mount time.  As such, the mount cannot be put
      in fstab(5) or similar.
  2 - When the TGT expires, the mount breaks.
- The client machine has a service principal in its default keytab
  file and this service principal (typically called a host-based
  initiator credential) is used as the machine credential.
  There are problems with this approach as well:
  1 - There is a certain amount of administrative overhead creating
      the service principal for the NFS client, creating a keytab
      entry for this principal and then copying the keytab entry
      into the client's default keytab file via some secure means.
  2 - The NFS client must have a fixed, well known, DNS name, since
      that FQDN is in the service principal name as the instance.

This patch uses a feature of NFSv4.1/4.2 called SP4_NONE, which
allows the state maintenance operations to be performed by any
authentication mechanism, to do these operations via AUTH_SYS
instead of RPCSEC_GSS (Kerberos).  As such, neither of the above
mechanisms is needed.

It is hoped that this option will encourage adoption of Kerberized
NFS mounts using TLS, to provide a more secure NFS mount.

This new NFSv4.1/4.2 mount option, called "syskrb5" must be used
with "sec=krb5[ip]" to avoid the need for either of the above
Kerberos setups to be done by the client.

Note that all file access/modification operations still require
users on the NFS client to have a valid TGT recognized by the
NFSv4.1/4.2 server.  As such, this option allows, at most, a
malicious client to do some sort of DOS attack.

Although not required, use of "tls" with this new option is
encouraged, since it provides on-the-wire encryption plus,
optionally, client identity verification via a X.509
certificate provided to the server during TLS handshake.
Alternately, "sec=krb5p" does provide on-the-wire
encryption of file data.

A mount_nfs(8) man page update will be done in a separate commit.

Discussed on:	freebsd-current@
MFC after:	3 months
2023-03-16 15:55:36 -07:00
..
nfs_fha_new.c nfs_fha_new: Fix nfs_fha_new so that sysctls work in prisons 2023-03-01 15:25:35 -08:00
nfs_fha_new.h nfs_fha_new: Fix nfs_fha_new so that sysctls work in prisons 2023-03-01 15:25:35 -08:00
nfs_nfsdcache.c nfsd: Add VNET_SYSUNINIT() macros for vnet cleanup 2023-02-20 13:11:22 -08:00
nfs_nfsdkrpc.c nfsd: Fix initialization broken by 7344856e3a6d 2023-02-12 09:16:56 -08:00
nfs_nfsdport.c nfscl: Add a new NFSv4.1/4.2 mount option for Kerberized mounts 2023-03-16 15:55:36 -07:00
nfs_nfsdserv.c nfscl: Add a new NFSv4.1/4.2 mount option for Kerberized mounts 2023-03-16 15:55:36 -07:00
nfs_nfsdsocket.c nfsd: Wrap nfsstatsv1_p in the NFSD_VNET() macro 2023-02-15 17:39:07 -08:00
nfs_nfsdstate.c nfscl: Add a new NFSv4.1/4.2 mount option for Kerberized mounts 2023-03-16 15:55:36 -07:00
nfs_nfsdsubs.c nfsd: Prepare the NFS server code to run in a vnet prison 2023-02-11 15:51:19 -08:00