Subject: Re: SunOS/Solaris "nobody" UID versus NetBSD's "nobody" UID
To: None <tech-security@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-security
Date: 11/27/1999 12:56:46
  by redmail.netbsd.org with SMTP; 27 Nov 1999 18:46:33 -0000
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <woods@most.weird.com>) 
	id <m11rm5W-000g6HC@most.weird.com>
	for tech-security@netbsd.org; Sat, 27 Nov 1999 12:56:46 -0500 (EST)
	(Smail-3.2.0.110-Pre 1999-Oct-27 #31 built 1999-Oct-28)
Message-Id: <m11rm5W-000g6HC@most.weird.com>
Date: Sat, 27 Nov 1999 12:56:46 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@most.weird.com (Greg A. Woods)
To: tech-security@netbsd.org
Subject: Re: SunOS/Solaris "nobody" UID versus NetBSD's "nobody" UID
In-Reply-To: <19991118122023.D2558@cs.hut.fi>
References: <v04210116b458c2bb6e62@[216.240.40.200]>
	<Pine.GSO.4.05.9911180113060.7482-100000@rfhs8036>
	<19991118122023.D2558@cs.hut.fi>
Reply-To: tech-security@NetBSD.ORG (NetBSD Security Technical Discussion List)
Organization: Planix, Inc.; Toronto, Ontario; Canada

[ On Thursday, November 18, 1999 at 12:20:23 (+0200), Antti Kantee wrote: ]
> Subject: Re: SunOS/Solaris "nobody" UID versus NetBSD's "nobody" UID
>
> jaddajaddajadda, guess that the uid of nobody is not that standard.
 
It's actually not important that it be standard unless you create files
owned by that UID and then expect to share them across NFS.

Note that strictly speaking I think the idea is (was?) that "nobody"
should never own anything or have any more than read (and sometimes
execute) permission on any file anywhere in the exported NFS
directories.  Unfortunately many developers and sys-admins have taken
the lazy way out and many programs and systems can be found which
default to using "nobody" as an application-specific private
unprivileged user and often with the need to create and/or write to
files that may themselves require protection from other "unprivileged"
users.  Perhaps if "nobody" had been called "nfsroot" from day one there
would have been less confusion.  Indeed with the current default uid/gid
of -2 it is less likely for NFS remote root users to affect applications
which are using the "nobody" user-id for their own purposes.

What is important, at least from my point of view, is that the system
default to mapping remote root accesses onto the same UID as is referred
to as "nobody" in the (possibly local) passwd file (or perhaps "nfsroot"
if we want to be brave and try to change the trend).  This probably
means changing mountd so that it first tries to lookup the credentials
for "nobody" (or "nfsroot") before it defaults to using "-2".  (Untested
example patch attached.)

The side issue is that if the magic number "-2" is going to continue to
be the default value then there are some ``fixes'' necessary in the
various library routines and utilities that do sanity checking on UIDs
because currently some of them will not allow a value of -2.  It is of
course only important to have a user-id with a uid of -2 if you want
getpw() to be able to find user information for the default NFS
unprivileged user (eg. if you do allow remote root users to create
and/or write to some files in your exported filesystems and you want to
identify these files by something other than the magic number "-2").  I
think this is important in a general sense, but it may not be so
important to everyone.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>

---------- untested example patch ----------

(the second hunk is an unrelated minor fix)

Index: mountd.c
===================================================================
RCS file: /cvs/NetBSD/src/usr.sbin/mountd/mountd.c,v
retrieving revision 1.1.1.4
diff -c -c -r1.1.1.4 mountd.c
*** mountd.c	1998/11/16 21:51:55	1.1.1.4
--- mountd.c	1999/11/27 17:32:09
***************
*** 1855,1863 ****
  	 * Set up the unpriviledged user.
  	 */
  	cr->cr_ref = 1;
! 	cr->cr_uid = -2;
! 	cr->cr_gid = -2;
! 	cr->cr_ngroups = 0;
  	/*
  	 * Get the user's password table entry.
  	 */
--- 1855,1882 ----
  	 * Set up the unpriviledged user.
  	 */
  	cr->cr_ref = 1;
! 	if ((pw = getpwnam("nfsroot"))) {
! 		cr->cr_uid = pw->pw_uid;
! 		ngroups = NGROUPS + 1;
! 		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
! 			syslog(LOG_ERR, "Too many groups for user: nfsroot");
! 		/*
! 		 * Convert from int's to gid_t's and compress out duplicate
! 		 */
! 		cr->cr_ngroups = ngroups - 1;
! 		cr->cr_gid = groups[0];
! 		for (cnt = 1; cnt < ngroups; cnt++)
! 			cr->cr_groups[cnt - 1] = groups[cnt];
! 	} else {
! 		/*
! 		 * assume default maproot to good old-fashioned "-2", though be
! 		 * warned that very few systems actually define a user-id with
! 		 * this value of uid.  Should this be syslog'ed?
! 		 */
! 		cr->cr_uid = -2;
! 		cr->cr_gid = -2;
! 		cr->cr_ngroups = 0;
! 	}
  	/*
  	 * Get the user's password table entry.
  	 */
***************
*** 1878,1884 ****
  		cr->cr_uid = pw->pw_uid;
  		ngroups = NGROUPS + 1;
  		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
! 			syslog(LOG_ERR, "Too many groups");
  		/*
  		 * Convert from int's to gid_t's and compress out duplicate
  		 */
--- 1897,1903 ----
  		cr->cr_uid = pw->pw_uid;
  		ngroups = NGROUPS + 1;
  		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
! 			syslog(LOG_ERR, "Too many groups for user: %s", name);
  		/*
  		 * Convert from int's to gid_t's and compress out duplicate
  		 */