Date: Mon, 29 Nov 1999 17:58:59 -0800 (PST) From: Kris Kennaway <kris@hub.freebsd.org> To: Doug Barton <Doug@gorean.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Dan Moschuk <dan@FreeBSD.ORG>, 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 Message-ID: <Pine.BSF.4.21.9911291751510.65191-100000@hub.freebsd.org> In-Reply-To: <Pine.BSF.4.21.9911291737310.32747-100000@24-25-220-29.san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.9911291751510.65191-100000>