From owner-freebsd-security@FreeBSD.ORG Wed Aug 13 18:42:23 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C611837B401 for ; Wed, 13 Aug 2003 18:42:23 -0700 (PDT) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64AC243FB1 for ; Wed, 13 Aug 2003 18:42:23 -0700 (PDT) (envelope-from mike@adept.org) Received: by fubar.adept.org (Postfix, from userid 1001) id 5ABA215256; Wed, 13 Aug 2003 18:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fubar.adept.org (Postfix) with ESMTP id 569031524D for ; Wed, 13 Aug 2003 18:42:23 -0700 (PDT) Date: Wed, 13 Aug 2003 18:42:23 -0700 (PDT) From: Mike Hoskins To: security@freebsd.org In-Reply-To: <20030812111522.GA66788@cirb503493.alcatel.com.au> Message-ID: <20030813183936.C4965@fubar.adept.org> References: <20030812085617.GA407@FreeBSD.org> <003501c360b0$6dad9970$9f8d2ed5@internal> <20030812111522.GA66788@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: realpath(3) et al X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2003 01:42:24 -0000 On Tue, 12 Aug 2003, Peter Jeremy wrote: > >Features such as a protected stack should, IMO, be implemented as soon as > >possible to keep FreeBSD heads-afloat right now in the security sense.... > >OpenBSD has implemented this already and there are many patches for Linux to > >do the same... why don't we go ahead and shove some of this code into CVS? > By "protected" I presume you mean "non-executable". Whilst making the > stack non-executable is trivial, making the system still work isn't. > I believe the FreeBSD signal handling still relies on a signal > trampoline on the stack. Some ports also expect an executable stack > (most commonly lisp implementations). i'd also just like to add an aside that's probably obvious... yes we want security, but we really want to give people options too... these sorts of measures can have a performance impact. as such, i feel we should always give users the option of turning them off/on via some easy to find knob (make.conf/define, kernel, etc.). -mrh -- From: "Spam Catcher" To: spam-catcher@adept.org Do NOT send email to the address listed above or you will be added to a blacklist!