From owner-freebsd-security Mon Dec 3 5:58:13 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 6596B37B416 for ; Mon, 3 Dec 2001 05:58:11 -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 fB3DvG721668 for ; Mon, 3 Dec 2001 07:57:16 -0600 (CST) Received: from 134.132.72.99 by lgchvw02.lgc.com (InterScan E-Mail VirusWall NT); Mon, 03 Dec 2001 07:58:01 -0600 Received: from vesna (oleg@[134.132.197.98]) by junior.lgc.com (8.11.3/8.11.3) with SMTP id fB3DvAS21653 for ; Mon, 3 Dec 2001 07:57:10 -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 14:57:55 +0100 X-Mailer: KMail [version 1.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01120314575508.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 Monday 03 December 2001 13:44, Robert Watson wrote: > On Mon, 3 Dec 2001, Alfred Perlstein wrote: > > * Oleg Cherkasov [011203 03:16] wrote: > > > Think a new key 'malloc.random' for sysctl could be more useful, > > > protected with 'kern.securelevel' > 1. > > > > However, malloc(3) has nothing to do with the kernel. > > Yeah, I'm not sure why it would be keyed off of 'securelevel'. Seems to > me that we should avoid any more userland cruft being associated > unnecessarily with securelevels, actually :-). > > And if we do stuff this in a securelevel, it sounds like we need a > userland. sysctl namespace. More likely, we just need > this to be a flag on /etc/malloc.conf. Yes, you are right, it is better to keep it out of the kernel. But except having /etc/malloc.conf, is it better to have a shell variable MEMORY_RANDOM or MALLOC_CONF? In this case just 'weak' services can be run with that option on. We still do not know how will it affect performance ... because it will be additional cycles during memory allocation for every single *alloc() call. Some software could be very aggressive using malloc(), who knows. Oleg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message