by redmail.netbsd.org with SMTP; 19 Nov 1999 06:23:54 -0000
	by digital.clock.org (8.8.8/8.8.5) with ESMTP id WAA19014
	for <tech-security@netbsd.org>; Thu, 18 Nov 1999 22:23:52 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v0421011db45a9876f5f5@[216.240.40.200]>
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>
Date: Thu, 18 Nov 1999 22:10:27 -0800
To: tech-security@NetBSD.ORG
From: Erik Fair <security-officer@NetBSD.ORG>
Subject: Re: SunOS/Solaris "nobody" UID versus NetBSD's "nobody" UID
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

OK, I think I see the pattern here:

1. nobody UID is "-2" (or an unsigned representation of same, 
bit-width dependent) which is consistent with default NFS mapping of 
root client access to an server.

2. nobody UID is an arbitrary value.

We currently fall into #2.

Consistency issues aside, I think the main security issue (why I 
brought it up here) is whether having a "nobody" UID in /etc/passwd 
would encourage system administrators to set file/directory ownership 
to that UID, and, in the presence of NFS, does that present a 
security exposure?

If we say "yes", then our current situation is OK, and we leave 
things as they are.

If we say "no", then we should change "nobody" to "-2" for better 
consistency with the rest of the world (not to mention our own 
mountd). I did a cursory walk through libc to try and find the passwd 
file parser (it used to be in getpwent.c) and failed to find it; I 
was trying to check if it will accept a negative number in the UID 
and GID fields of /etc/passwd (and /etc/group).

Any further thoughts along this line?

	pondering ponderously,

	Erik <fair@clock.org>