From owner-freebsd-security  Sat Dec  1  8:42:42 2001
Delivered-To: freebsd-security@freebsd.org
Received: from lariat.org (lariat.org [12.23.109.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 36A5937B42B; Sat,  1 Dec 2001 08:42:28 -0800 (PST)
Received: (from brett@localhost)
	by lariat.org (8.9.3/8.9.3) id JAA09819;
	Sat, 1 Dec 2001 09:42:14 -0700 (MST)
Date: Sat, 1 Dec 2001 09:42:14 -0700 (MST)
From: Brett Glass <brett@lariat.org>
Message-Id: <200112011642.JAA09819@lariat.org>
To: phk@FreeBSD.ORG, security@FreeBSD.ORG
Subject: Re: philosophical question...
In-Reply-To: <36180.1007217784@critter.freebsd.dk>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-security.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-security>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-security>
X-Loop: FreeBSD.org

> Would it inconvenience debugging that malloc(3) becomes non
> deterministic in its layout ?

> Would the increased uncertainty on program run-time be 
> good or bad ?

It could make reproduction of problems more difficult. So, if
it goes in, I'd like a switch to turn it off.... Maybe a
sysctl.

But there's a more serious philosophical issue here. Isn't
shuffling the heap to avoid attacks really a form of
"security via obscurity?"

--Brett Glass

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message