Date: Mon, 29 Nov 1999 17:47:30 -0800 (PST) From: Doug Barton <Doug@gorean.org> To: Kris Kennaway <kris@hub.freebsd.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.9911291737310.32747-100000@24-25-220-29.san.rr.com> In-Reply-To: <Pine.BSF.4.21.9911291319580.51314-100000@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Nov 1999, Kris Kennaway wrote:
> 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.
Personally I agree with this principle, and agree that options of
this sort should be on by default.
> * 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.
Any security feature that can cause a performance hit (and we can
argue that definition another time) should be optionable, including
"small ones." I have some systems where _every_ cpu cycle is non-trivial,
so I want the ability to push some of my security downstream and just let
the box do its job.
> * 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
microsoft, and we're not pushing a "one best way" on our users. My feeling
is that _every_ kernel option should have a compile/link-time component
(whether that is config-able, or fits into whatever new structure we come
up with) AND a sysctl knob wherever possible. Just because this hasn't
been done in the past doesn't mean this isn't a good time to start.
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
thing, bad security is worse than none. I do think that random source port
numbers is a bonus, for the reasons that Warner already addressed, and
because it makes spoofing packets _coming_ from your machine somewhat
harder.
FWIW,
Doug
--
"Welcome to the desert of the real."
- Laurence Fishburne as Morpheus, "The Matrix"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" 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.9911291737310.32747-100000>