Date: Tue, 23 Apr 2002 11:35:03 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Mike Barcroft <mike@FreeBSD.ORG> Cc: Mike Silbersack <silby@silby.com>, Garrett Wollman <wollman@lcs.mit.edu>, "M. Warner Losh" <imp@village.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: <Pine.NEB.3.96L.1020423113228.55944B-100000@fledge.watson.org> In-Reply-To: <20020423105336.E72727@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Apr 2002, Mike Barcroft wrote:
> Mike Silbersack <silby@silby.com> writes:
> > On Mon, 22 Apr 2002, Mike Barcroft wrote:
> >
> > > I agree that the current solution to this problem is wrong. I think
> > > the most correct solution would be to fix each set[ug]id program to
> > > ensure that it has a working set of the basic std{in,out,err}
> > > descriptors by making a series of fstat() calls and watching for a
> > > EBADF.
> > >
> > > Best regards,
> > > Mike Barcroft
> >
> > But... if you go through and fix the bugs in the various set[ug]id
> > programs, doesn't that make the kernel change a no-op? And in that case,
> > what's the harm in having such a feature in the kernel?
>
> See the prior discussion; it breaks conformance to the Standard.
> There's no reason a conforming program couldn't use closed file
> descriptors to relay a message to a an exec()'d process, for instance.
We already break plenty of standards for setuid binaries. This is nothing
different. For example, rules for signal delivery are substantially
tightened on FreeBSD for setuid binaries when executing. Also, we
introduce protections whenever there is a credential "downgrade" to deal
with information leakage in free'd memory and libraries. If you run
various signal delivery compliance tests and combine that with setugid
programs, you'll get non-compliant failures. We now have a long history
of offering behavioral exemptions for setugid binaries in execution, since
that execution environment is extremely hard to program for, and often has
complications programmers can't/don't know about. A while ago, for
example, I looked at tightening signal delivery protections for
non-setugid binaries, and bde e-mailed me with a list of results from a
conformance suite that we violate. I backed out the commit, but left
things as they were for setugid--we'd been violating conformance
requirements there for many years.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
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?Pine.NEB.3.96L.1020423113228.55944B-100000>