From owner-freebsd-security Sat Jun 20 04:21:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA14392 for freebsd-security-outgoing; Sat, 20 Jun 1998 04:21:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from wumpus.its.uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA14379 for ; Sat, 20 Jun 1998 04:21:15 -0700 (PDT) (envelope-from ncb05@uow.edu.au) Received: from banshee.cs.uow.edu.au (ncb05@banshee.cs.uow.edu.au [130.130.188.1]) by wumpus.its.uow.edu.au (8.9.0.Beta5/8.9.0.Beta5) with SMTP id VAA16064 for ; Sat, 20 Jun 1998 21:21:14 +1000 (EST) Date: Sat, 20 Jun 1998 21:21:14 +1000 (EST) From: Nicholas Charles Brawn X-Sender: ncb05@banshee.cs.uow.edu.au To: security@FreeBSD.ORG Subject: non-executable stack? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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? Nick -- Email: ncb05@uow.edu.au - http://rabble.uow.edu.au/~nick Key fingerprint = DE 30 33 D3 16 91 C8 8D A7 F8 70 03 B7 77 1A 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message