From owner-cvs-all Tue Apr 23 8:35:20 2002 Delivered-To: cvs-all@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0554B37B400; Tue, 23 Apr 2002 08:35:14 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g3NFZ3w84442; Tue, 23 Apr 2002 11:35:03 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 23 Apr 2002 11:35:03 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Barcroft Cc: Mike Silbersack , Garrett Wollman , "M. Warner Losh" , 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 In-Reply-To: <20020423105336.E72727@espresso.q9media.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 23 Apr 2002, Mike Barcroft wrote: > Mike Silbersack 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