Date: Fri, 11 May 2012 21:45:11 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions Message-ID: <1493074817.296570.1336787111152.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120511122020.GA13906@pm513-1.comsys.ntu-kpi.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrey Simonenko wrote: > On Thu, May 10, 2012 at 04:34:15PM -0400, Rick Macklem wrote: > > Andrey Simonenko wrote: > > > > > in RFC 3530. (It may be implied by the fact that NFSv4 uses a > > > > "user" > > > > based > > > > security model and not a "host" based one.) > > > > > > > > As such, the client should never need to "waste" a reserved > > > > port# on > > > > a NFSv4 > > > > connection. > > > > > > Since AUTH_SYS can be used in NFSv4 as well and according to RFC > > > 3530 > > > AUTH_SYS in NFSv4 has the same logic as in NFSv2/3, then > > > > > > 1. Does "user" based security model mean RPCSEC_GSS? > > > > > > 2. Does "host" based security model mean AUTH_SYS? > > > > > My guess is that AUTH_SYS is not considered a security model at all, > > but the "authenticators" refer to users. > > Probably I wrongly asked the question. I did not mean that some > security > flavor (eg. AUTH_SYS) is a security model. I wanted to say that NFSv4 > allows to use AUTH_SYS security flavor and user credentials are given > as is by client's machine, so some form of control by client's IP > address > is required by the NFSv4 server if a client uses and is allowed to use > AUTH_SYS security flavor. Actually this is specified in "16. Security > Considerations" from RFC 3530 and AUTH_SYS in NFSv4 is called << > "classic" > model of machine authentication via IP address checking >>. > > What do you think about the following idea about configuration? > > 1. The NFS server for NFSv2/3 clients allows to specify whether their > MOUNT MNT, UMNT and UMNTALL RPC requests have to or do not have to > come > from reserved ports. > > 2. The NFS server for NFSv2/3/4 clients allows to specify whether > their > NFS RPC calls: > a) do not have to come from reserved ports > b) always have to come from reserved ports > c) have to come from reserved ports if clients use AUTH_SYS. > > 3. By default reserved ports are not required for MOUNT RPC and > NFS RPC calls. Corresponding options can be used for entire file > system and/or for single address specification. > > First item obviously is checked in a user space and second item is > checked > in the NFS server somewhere after VFS_CHECKEXP() when the server > decides > which security flavor to use. > One problem with this is that some NFSv4 operations do not have any file handle and, as such, cannot be associated with any exported file system. (I suppose you could add the export option for resvport to the V4: line like I did with "-sec" for these operations, but it will get messy.) > 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. > > Personally, I agree with the working group and have always thought > > requiring > > a client to use a "reserved port#" was meaningless. However, I > > already noted > > that I don't mind enabling it, with a comment that it should not be > > required > > for NFSv4. > > 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.) 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. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1493074817.296570.1336787111152.JavaMail.root>