Re: [PATCH nfs-utils] exportfs: make "insecure" the default for all exports

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2025-05-19 at 16:02 +1000, NeilBrown wrote:
> On Fri, 16 May 2025, Chuck Lever wrote:
> > 
> > Fair enough. We'll focus on improving the man page text for now.
> > 
> 
> Has anyone volunteered to do that?
>
> Here are some words that might be useful.  I haven't tried to structure
> them to fit well into the man page.

Thanks Neil.

I was planning to write up a manpage patch for this once the dust had
settled from this discussion. I'll plan to incorporate something like
what you've written below.

> ---------------
> sec=sys (also known as AUTH_SYS) is only safe to specify for clients
> that are connected to the server by a secure network - either physically
> secure such as in a locked room, or cryptographically secure such as
> with a VPN where the client hardware is also secure (locked cage or
> secure-boot etc).
> 
> When such physical and/or crypto security is in place sec=sys can
> safely be used and there is an extra configuration option available in
> a choice between the "secure" and "insecure" export options.  
> 
> "insecure" means that all software running in the client node is fully
> trusted to only access files on the NFS exports that it is expected to
> access.  In this case the server will accept connections from any TCP
> port on the client (and messages from any UDP port) - as they can
> equally be trusted.
> 
> "secure" means that the clients are Unix-like systems and that only
> "admin" software such as the kernel and administrative software running
> as "root" can be trusted to access files appropriately.  All other
> software, which includes all user-space software running with a UID
> other than zero, should be treated with caution and not given direct
> access to the NFS server.  In this case the server will reject
> connections from TCP ports on the client with numbers not less than 1024
> (and UDP messages from ports not less than 1024) as such connections an
> messages may be from an untrusted process.  Note that on Unix-like
> systems only privileged processes can send from ports below 1024.
> 
> The "secure" option is enabled by default as it is least likely to give
> away undesired access.  Note that the names of the options do not
> clearly match the descriptions given.
> 
> -------------
> 
> I haven't added anything about mtls as I couldn't find out how nfsd
> interprets the identity presented in the client-side certificate.  If
> the identity is a "machine identity" then sec=sys would make sense on
> that connection.  If the identity is for a specific user and can map to
> a uid, the all_squash,anon=UID should be imposed on that connection.
> 
> Can you point me to any documentation about how the client certificate
> is interpreted by nfsd?


-- 
Jeff Layton <jlayton@kernel.org>