Date: Tue, 23 Apr 2002 12:19:15 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: "M. Warner Losh" <imp@village.org> Cc: mike@FreeBSD.org, nectar@FreeBSD.org, phk@critter.freebsd.dk, wollman@lcs.mit.edu, 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.1020423121727.91313L-100000@fledge.watson.org> In-Reply-To: <20020423.101656.38781717.imp@village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Apr 2002, M. Warner Losh wrote: > In message: <20020423120949.G72727@espresso.q9media.com> > Mike Barcroft <mike@FreeBSD.org> writes: > : A user should be able to choose the security policy of his/her system. > : If that means one has to add `option POSIX_SETUGID_HANDLING', that's > : fine, but to force a security policy down a user's throat, I think, is > : wrong. This applies to Robert's comments as well. > > How is that different than access controls or memory protection between > processes? Well, depending on how complete he wants to be, we could just call it: #options WEAK_POSIX_INTERPROCESS_SECURITY # Introduce known # vulnerabilities :-) Such an option could disable the various "special" protections we have for setugid, including debugging protection, issetugid(), signal protections, etc. Given that the debugging interface probably isn't in POSIX (don't remember off hand, but suspect strongly not), that can be left out; it's the signalling and exec behavior that may be most relevant. Of course, my recollection is that various conformance suites avoid touching the setugid case anyway, so... 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.1020423121727.91313L-100000>