Date: Fri, 11 May 2012 15:20:20 +0300 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions Message-ID: <20120511122020.GA13906@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <901330725.234130.1336682055896.JavaMail.root@erie.cs.uoguelph.ca> References: <20120510130731.GA72837@pm513-1.comsys.ntu-kpi.kiev.ua> <901330725.234130.1336682055896.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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. NetBSD already has -noresvmnt and -noresvport options in their exports(5). > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120511122020.GA13906>