From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 04:32:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07E6A16A4CE for ; Sat, 18 Sep 2004 04:32:35 +0000 (GMT) Received: from skippyii.compar.com (webpos.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45FBB43D53 for ; Sat, 18 Sep 2004 04:32:34 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])i8I4bws9040513; Sat, 18 Sep 2004 00:38:00 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: , "Avleen Vig" References: <4146316C000077FD@ims3a.cp.tin.it><20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk><20040918025217.GB54961@silverwraith.com> <20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk> Date: Sat, 18 Sep 2004 00:29:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 04:32:35 -0000 > 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