In message <Pine.LNX.4.33.0109061604190.32214-100000@denkigama.nat.shibuya.blin
k.co.jp>, Curt Sampson writes:
>On Wed, 5 Sep 2001, Steven M. Bellovin wrote:
>
>> We are not trying to administer single machines today.
>
>Uh..."woah!" Some of us are. Some of us aren't.
>
>> I need to be able to
>> say "here's a new binary package (or pointer to a package); install it
>> on the following 300 machines".
>
>You need that. I don't, at least not for any sites where I set the
>security policy.

I personally administer four NetBSD machines, not 300 -- but even with 2, 
I want a better way to handle patches and upgrades.  No two of my four 
machines have a consistent set of patches, a fact I'm not proud of.
>
>There are sites where I do some administrative work where this sort of
>thing is required, and in fact what we do is set "PermitRootLogin" to
>"yes", which makes sense to me.
>
>Or has this thread changed from a discussion of what NetBSD should ship
>with as a default to what individual admins should set (or be compelled
>to set) at their sites?

I think that that's the wrong question.  I want to know what NetBSD 
should do structurally so that either choice is safe.  Greg is right 
about the risks, but a system that is secure only in unrealistic 
circumstances is useless.  Yes, the defaults should be very secure, 
since not everyone needs all features, and any extra feature is an 
unnecessary risk.  But the core "optional" features have to be secure, 
no matter what.  (I'm reminded of NT's C2 rating -- which was only 
valid if you had no network, no floppy, etc.)

A second question is what the core features are; beyond that, we have 
to ask how to secure a system so that if one subsystem is compromised, 
the whole machine isn't taken over.  But that's a research area; we're 
not going to solve it here and now.

		--Steve Bellovin, http://www.research.att.com/~smb