Received-SPF: pass (google.com: domain of linux-nfs+bounces-3129-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 2 May 2024 11:54:43 -0400
From: Scott Mayhew <smayhew@redhat.com>
To: linux-nfs@vger.kernel.org
Subject: NFSv3 and xprtsec policies
Message-ID: <ZjO3Qwf_G87yNXb2@aion>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Red Hat QE identified an "interesting" issue with NFSv3 and TLS, in that an
NFSv3 client can mount with "xprtsec=none" a filesystem exported with
"xprtsec=tls:mtls" (in the sense that the client gets the filehandle and adds a
mount to its mount table - it can't actually access the mount).

Here's an example using machines from the recent Bakeathon.

Mounting a server with TLS enabled:

# mount -o v4.2,sec=sys,xprtsec=tls oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt
# umount /mnt

Trying to mount without "xprtsec=tls" shows that the filesystem is not exported with "xprtsec=none":

# mount -o v4.2,sec=sys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt
mount.nfs: Operation not permitted for oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls on /mnt

Yet a v3 mount without "xprtsec=tls" works:

# mount -o v3,sec=sys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt
# umount /mnt

and a mount with no explicit version and without "xprtsec=tls" falls back to
v3 and also "works":

# mount -o sec=sys oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt
# grep ora /proc/mounts
oracle-102.chuck.lever.oracle.com.nfsv4.dev:/export/tls /mnt nfs
+rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=100.64.0.49,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=100.64.0.49 0 0

Even though the filesystem is mounted, the client can't do anything with it:

# ls /mnt
ls: cannot open directory '/mnt': Permission denied

When krb5 is used with NFSv3, the server returns a list of pseudoflavors in
mountres3_ok (https://datatracker.ietf.org/doc/html/rfc1813#section-5.2.1).
The client compares that list with its own list of auth flavors parsed from the
mount request and returns -EACCES if no match is found (see
nfs_verify_authflavors()).

Perhaps we should be doing something similar with xprtsec policies?  Should
there be an errata to RFC 9289 and a request from IANA for assigned numbers for
pseudo-flavors corresponding to xprtsec policies?

If not, this behavior should at least be documented in the man pages.

-Scott