Date: Sat, 18 Sep 2004 00:29:36 -0400 From: "Matt Emmerton" <matt@gsicomp.on.ca> To: <viro@parcelfarce.linux.theplanet.co.uk>, "Avleen Vig" <lists-freebsd@silverwraith.com> Cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow Message-ID: <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca> References: <4146316C000077FD@ims3a.cp.tin.it><20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk><20040918025217.GB54961@silverwraith.com> <20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Sep 17, 2004 at 07:52:18PM -0700, Avleen Vig wrote: > > The difference is, that calling panic(9) is not a bug, it's a designed > > mechanism to panic a kernel. > > The behaviour reported is NOT designed behaviour (at least, no-one has > > said it is). > > > > Therefore, if the man wants to write a patch to fix unintended > > behaviour, what's wrong with that? > > Extra code on a time-critical path with no sane use whatsoever. Note > that anyone who adds a syscall (or a library function, for that matter) > with that many arguments deserves public humiliation for terminal lack > of taste, so it's not going to help anything that wouldn't be worth > rm -rf... I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of "we don't need to protect against this case because anyone who does this is asking for trouble anyway" is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) An article posted today on Slashdot ( http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html ) points out that this attitude as a key reason why OSS code isn't neccessarily more secure than commercial counterparts, even though there are more eyes on the source. We have to realize the fact that there *are* insecure FreeBSD installations out there, and because of the OSS nature of FreeBSD, the availability of the source code and public mailing lists like this one (which highlight possible security holes) makes the development of exploits much, much easier. The argument of "extra code on a time-critical path" is valid, but only if we're concerned about building the fastest BSD out there. However, we can provide a choice to system administrators by wrapping these sanity checks with a runtime if-check of a sysctl value, or a compile-time #define, much like we use for WITNESS or INVARIANTS today. I'm reminded of the old adage of "good, fast, cheap -- choose two". There's nothing preventing us from implementing all three and leaving the choice of which two to use up to the end-user. -- Matt Emmerton
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001801c49d38$1c8cb790$1200a8c0>