From owner-freebsd-arch Mon Nov 29 13:27:55 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 549EE14F2E for ; Mon, 29 Nov 1999 13:27:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA24147 for ; Mon, 29 Nov 1999 22:27:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA66274 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 22:27:51 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id BEAE814C1F; Mon, 29 Nov 1999 13:27:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id ABB3C1CD473; Mon, 29 Nov 1999 13:27:42 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 13:27:42 -0800 (PST) From: Kris Kennaway To: Matthew Dillon Cc: Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <199911292104.NAA09106@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Nov 1999, Matthew Dillon wrote: > Hi Dan. Is it possible that we could adjust this feature to be enabled > with a config option? It seems to add a considerable amount of bulk to > the kernel that's deadweight for the people not using it. This raises some larger architectural issues which probably should be dealt with. Namely: * Changes which tighten security are arguably only useful if they're on by default, otherwise all the newbies will leave them off, and have (relatively speaking) insecure boxes. * Just what is the "scope" of the auditing project under which this change (and many others to come) falls? In other words, how much security do we (FreeBSD) want, and at what expense? Some of the OpenBSD changes have demonstrable security benefits, but they also carry a performance penalty. * Is adding a few bytes to the kernel size really an issue compared to the complexity of having 20 different config options to include/exclude various kernel security features? Personally, I'm quite happy with a policy of "include everything which doesn't have a large performance hit, by default, and have the rest defaulting to 'off' with a trivial way for people to turn it on", but maybe that's just me being a security weenie :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message