From owner-freebsd-arch Mon Nov 29 18: 0:44 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 543F914EEF for ; Mon, 29 Nov 1999 18:00:37 -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 DAA26752 for ; Tue, 30 Nov 1999 03:00:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA67879 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 03:00:37 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id E12BB15691; Mon, 29 Nov 1999 17:58:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CE9BE1CD623; Mon, 29 Nov 1999 17:58:59 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 17:58:59 -0800 (PST) From: Kris Kennaway To: Doug Barton Cc: Matthew Dillon , 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: 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, Doug Barton wrote: > > * 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? > > Sorry, "kernel option complexity" is a red-herring argument. If > the options are well thought out, given sensible defaults and thoroughly > documented that whole argument just dries up and blows away. This isn't This doesn't seem to be the way other people have been pushing..I'm pretty sure there have been cases recently where it was decided against making a new feature a config option on the grounds of #ifdef HELL. For large changes I definitely agree, but not for trivial (e.g. 1-line, like this one) changes. There will probably end up being 20 or so randomized features in the kernel, most of them trivial (~1 line) patches. As long as they're sysctl'able, is it really necessary to have each of them optionable? > As for random pids, I would turn this off with extreme > prejudice. I don't think it gains us much, if anything (and yes, I > understand the /tmp race arguments, I just think they are better solved > elsewhere) and as Mark Murray said in relation to the forth boot password I'd appreciate some suggestions about how we can fix them in the case of third-party binaries (esp. statically-linked ones). > thing, bad security is worse than none. I agree, but I don't think it applies in this case. It converts a trivially exploitable hole into a quite difficult to exploit race, which is the best I can think of, and measurably improves security. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message