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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120511122020.GA13906>