From owner-freebsd-security Mon Dec 3 1:16:46 2001 Delivered-To: freebsd-security@freebsd.org Received: from junior.lgc.com (junior.lgc.com [134.132.72.99]) by hub.freebsd.org (Postfix) with ESMTP id EE5ED37B405 for ; Mon, 3 Dec 2001 01:16:42 -0800 (PST) Received: from lgchvw02.lgc.com (lgchvw02.lgc.com [134.132.93.108]) by junior.lgc.com (8.11.3/8.11.3) with SMTP id fB39Fm726188 for ; Mon, 3 Dec 2001 03:15:48 -0600 (CST) Received: from 134.132.72.99 by lgchvw02.lgc.com (InterScan E-Mail VirusWall NT); Mon, 03 Dec 2001 03:16:33 -0600 Received: from vesna (oleg@[134.132.197.98]) by junior.lgc.com (8.11.3/8.11.3) with SMTP id fB39FfS26171 for ; Mon, 3 Dec 2001 03:15:42 -0600 (CST) Content-Type: text/plain; charset="iso-8859-1" From: Oleg Cherkasov Organization: http://oleg.dnsalias.com To: freebsd-security@freebsd.org Subject: Re: philosophical question... Date: Mon, 3 Dec 2001 10:16:26 +0100 X-Mailer: KMail [version 1.2] References: <200112011658.fB1Gwep07621@cwsys.cwsent.com> In-Reply-To: <200112011658.fB1Gwep07621@cwsys.cwsent.com> MIME-Version: 1.0 Message-Id: <01120310162607.10748@vesna> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Saturday 01 December 2001 17:57, Cy Schubert - ITSD Open Systems Group wrote: > In message <200112011642.JAA09819@lariat.org>, Brett Glass writes: > > > 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?" > > Defence through depth. Every little bit helps. I think we should do > this. > > I suppose we could have a malloc.conf bit to turn this feature off (on > by default). Think a new key 'malloc.random' for sysctl could be more useful, protected with 'kern.securelevel' > 1. Oleg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message