Date: Wed, 13 Jan 1999 08:38:56 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: FreeBSD Security <security@FreeBSD.ORG> Subject: Re: GIDs for new default system `users' Message-ID: <Pine.BSF.3.96.990113082438.28048B-100000@fledge.watson.org> In-Reply-To: <XFMail.990113100259.asmodai@wxs.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
In my view, the kmem sandbox does not prevent a bug in a kmem utility from gaining root access. Kmem allows access to kernel memory, and kernel memory buffers are used to transfer sensitive date (such as keyboard input) meaning kmem access could be used to retrieve passwords, cryptographic material, etc, destined to and from other processes without authorization. As such, kmem would almost always imply root access eventually and with appropriate monitoring of kernel memory space. Kmem utilities should really be using /proc, sysctl, or some other carefully designed mechanism to mediate access to kernel data structures, not the general purpose file system interface of /dev/kmem, which should probably eventually go away in any securelevel, as it constites a violation of seperation of kernel and root privileges. Like a lot of other pseudo-security features involving uids, kmem gives you a false sense of comfort :). On the other hand, the bind sandbox sounds useful, as it reduces the need for a long-running uid 0 process that could have bugs in its large associated program (bind). Only small portions of bind actually require privileges operation (to bind the domain port for incoming and outgoing connections), so giving up those privileges and executing as the bind-sandbox user reduces the scope of attacks based on security wholes elsewhere in the bind source code. Some operating systems make a distinction between the nobody/nogroup users and other users, but I believe that FreeBSD does not. For example, I believe that some operating systems do not allow nobody to own files in the file system (I don't recall which); this is clearly not the case under FreeBSD/apache as CGI scripts can modify/create files if directory permissions are set appropriately. Running apache as nobody may be a mistake if someone believes this places it in a unique sandbox--at least one program (fingerd) is run by inetd as the nobody uid, meaning that a bug in fingerd could allow interference with web server execution, etc. More likely, of course, the web server contains a bug, as it is significantly more complex a program. nobody is nobody by virtue of not a) being associated with any files, and b) being used by applications that may not have authenticated their users (anonymous ftp uses the ftp account instead though :). It might be better, given that nobody ends up being the uid for CGI, if we formally introduced a 'www' user and used that instead (or apache-sandbox or something). Clearly, there is a difference between AFS's or Coda's concept of System:Anyuser and nobody: System:Anyuser is unauthenticated by definition; nobody is unauthenticated by convention, and it's not clear how well-followed the convention is. (this is my belief anyway, people should feel free to correct me :) On Wed, 13 Jan 1999, Jeroen Ruigrok/Asmodai wrote: > Hi guys, > > I have a question/remark I am very well concerned with... > > In the latest CURRENT /usr/src/etc/master.passwd there exist two new > users, mainly tty-sandbox and kmem-sandbox. These users are given the GID > of nogroup(65533). > > I recently had a whole discussion about user and group id's with our local > Unix guru and what he told me made perfect sense to me. What he said was > basically that every user or group can never be nobody or no-one since they > have an entry in the group or master.passwd file. He also told me that alot > of people make something like Squid and Apache members of nogroup/nobody > because these aren't accounts. IMHO that's completely wrong since they > belong to a group and can thus always be compromised and if alot of > programs are members of one group that means a lot of potential holes. > > Is there something specific about nogroup btw, that it has this explicit > name? If not, if it's bascially the same as nobody, then I am all in favor > of moving those tty-sandbox and kmem-sandbox to their own group id's for > the sake of security... > > Comments? > > --- > Jeroen Ruigrok van der Werven A veil of smoke is what I am, > asmodai(at)wxs.nl I wait and I wait... > Network/Security Specialist <http://home.wxs.nl/~asmodai>; > BSD & picoBSD: The Power to Serve <http://www.freebsd.org>; > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990113082438.28048B-100000>