From owner-freebsd-security Sun Jun 21 23:24:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27972 for freebsd-security-outgoing; Sun, 21 Jun 1998 23:24:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27664; Sun, 21 Jun 1998 23:23:31 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id XAA16784; Sun, 21 Jun 1998 23:19:50 -0700 (PDT) Message-Id: <199806220619.XAA16784@implode.root.com> To: Nicholas Charles Brawn cc: security@FreeBSD.ORG, bde@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: non-executable stack? In-reply-to: Your message of "Sat, 20 Jun 1998 21:21:14 +1000." From: David Greenman Reply-To: dg@root.com Date: Sun, 21 Jun 1998 23:19:50 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I was pondering the following after reading about solaris 2.6's >non-executable stack option. > >1. How feasible is it to implement a non-executable stack kernel option? >2. If it *is* feasible, what do people think of a sysctl-based interface >to enable/disenable it? >3. If both 1 & 2 were implemented, how about making it impossible to >disenable at say.. securelevel >= 1? > >If I remember the discussions on bugtraq right, a non-exec patch isn't a >cure-all for buffer overflow attacks. However it would be an overall >security enhancement and prevent many script-based attacks. > >What are peoples thoughts on this? I believe that making the stack non-exec will break the signal trampoline in FreeBSD. Although this may have changed in recent times without me noticing. Bruce? Peter? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message