NFSv4 Questions

[Andrey Simonenko]

On Fri, May 11, 2012 at 09:45:11PM -0400, Rick Macklem wrote:
> Andrey Simonenko wrote:
> 
> > NetBSD already has -noresvmnt and -noresvport options in their
> > exports(5).
> > 
> I'll let others comment w.r.t. whether they have a need for this. To me,
> unless others are saying "we need this", I don't see any reason to change
> what is already there, except maybe optionally require a reserved port#
> for NFSv4 mounts via a sysctl. I comment on this further down.

According to exports(5) manual page for Linux, similar option named
"secure" also exists in Linux NFS server implementation.  [1]

> > If a client machine is trusted, then reserved ports can guaranty that
> > requests come from privileged processes and not from user space where
> > client can fill any credentials in AUTH_SYS. If client machine is not
> > trusted, then this will not work of course. BTW mountd requires
> > reserved
> > port and NFS server does not required reserved port by default.
> Well, I agree that, if you have a client machine where "root" is secure
> (no root kit vunerabilities, etc) but non-root users on this machine
> would potentially run their own bogus userland NFS client, then requiring
> a reserved port# does subvert the use of such a bogus NFS client.
> (My concern is that some people will think that requiring a reserved port#
>  makes NFS secure for other cases, like users with their own laptops/desktops.)

Current implementation allows to export subdirectories to NFSv2/3 clients.
A NFSv2/3 client can guess a filehandle and access any part of exported file
system.  This is more insecure by design, than option that allows to specify
whether reserved port is required for NFS RPC requests.  Similar logic is
given in RFC2623.

> Personally, I think the above case is rare and that having another sysctl
> vfs.nfsd.nfsv4_privport (similar to vfs.nfsd.nfs_privport) is sufficient,
> but I'll let others comment on this, since it is not my decision.

Since nobody commented these ideas, I want to give description of my
implementation.  If somebody wants to do something similar for mountd,
then this description will give some information for thinking at least.

Command option for MOUNT protocol settings:

 -m mntset
         Specifies whether ... should service MOUNT protocol requests and
         what it should support from this protocol.  The argument is a
         colon separated list of values: no disables the protocol support,
         v1 supports version 1 of the protocol (used in NFSv2), v3 sup-
         ports version 3 of the protocol (used in NFSv3), udp, tcp, udp6
         and tcp6 specify which netconfig should be supported for the pro-
         tocol.  Disabling MOUNT protocol or some its version does not
         disable NFSv2/3 in the NFS server, the same logic is applied for
         disabled netconfigs.

Configuration options:

 -mnt_mount=arg1[:arg2...]
         Specify settings for MOUNT protocol's procedures MNT, UMNT and
         UMNTALL.  Available arguments are: default (set default set-
         tings), regfile (allow MNT requests for regular files), resvport
         (allow requests from reserved IP ports numbers only).  By default
         MNT requests are allowed for directories only, all requests are
         allowed from any IP port number.

 -resvport=value
         Specify whether NFS and NLM RPC requests should be received from
         sender's reserved IP port numbers (less than 1024).  Available
         arguments are: default (set default settings), always (reserved
         sender's IP port number is always required), weakauth (reserved
         sender's IP port number is required if the AUTH_SYS security fla-
         vor is used).  By default reserved sender's IP port numbers are
         not required.

Well, -resvport option does not work well for NLM RPC requests if
non-AUTH_SYS security flavor is used and user credentials on a client
differ with user credentials on a server.  But NLM does not work
in such configuration even without this options, details here [2].

[1] http://www.linuxmanpages.com/man5/exports.5.php
[2] http://lists.freebsd.org/pipermail/freebsd-fs/2012-May/014444.html