Date: Thu, 18 Apr 2002 22:01:25 -0600 (MDT) From: "M. Warner Losh" <imp@village.org> To: wollman@lcs.mit.edu Cc: nectar@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_descrip.c kern_exec.c src/sys/sys filedesc.h Message-ID: <20020418.220125.06947209.imp@village.org> In-Reply-To: <200204190309.g3J39tE69057@khavrinen.lcs.mit.edu> References: <200204190045.g3J0jUY59526@freefall.freebsd.org> <200204190309.g3J39tE69057@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200204190309.g3J39tE69057@khavrinen.lcs.mit.edu>
Garrett Wollman <wollman@lcs.mit.edu> writes:
: <<On Thu, 18 Apr 2002 17:45:30 -0700 (PDT), Jacques Vidrine <nectar@FreeBSD.org> said:
:
: > When exec'ing a set[ug]id program, make sure that the stdio file descriptors
: > (0, 1, 2) are allocated by opening /dev/null for any which are not already
: > open.
:
: >shudder<
:
: This seems completely and utterly broken to me.
OpenBSD did this two years ago, and nothing has busted.
The problem is that it can't be done in userland. I can always create
a shell that leaves stderr unopened. The program in question opens a
file (it gets fd 2 due to how unix works). Sometime later on in the
run, you force an error to happen. The error message gets written out
on stderr, splatting this file. For a setuid program, this represents
a security hole. There are many other examples than this one.
There is no other way to fix this than in the kernel...
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020418.220125.06947209.imp>