Date: Thu, 12 Oct 2000 01:36:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: drosih@rpi.edu (Garance A Drosihn) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), dillon@earth.backplane.com (Matt Dillon), arch@FreeBSD.ORG Subject: Re: cvs commit: src/etc inetd.conf Message-ID: <200010120136.SAA12021@usr09.primenet.com> In-Reply-To: <v04210100b60aa17e4957@[128.113.24.47]> from "Garance A Drosihn" at Oct 11, 2000 07:25:20 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Why are people (both sides) so worked up about this?
Because the people who want it locked down by default are
trying to implicitly limit the rest of us to only installing
"the right way" which is "the ways we do installs". They
are also implicitly constraining the definition of "useful
default system" to "the way we like to configure our systems".
Understandably, people get upset when they are being limited
or restrained, particularly if there are no really sound
arguments for hard-wiring instead of soft-wiring, which, if
hard-wired, would turn "unnecessary pain in the ass" into
"impossible to not do our way; our way is right".
So far, I have not seen one analysis that shows that ssh, as
configured by default, and used to obtain root access via a
network console, as the only console on an initially installed
system, is any more secure from session replay, spoofing, or
man-in-the-middle attacks.
The only arguement in favor of such an approach is that it
prevents casual sniffers from seeing the session contents.
This is the old "security through obscurity" argument.
It's all a matter of the amount of effort your opponent is
going to throw at cracking the system: not a matter of whether
or not the system is crackable. If they "own" the network on
which you are trying to install, then you're sunk anyway,
without a physical console to prevent network based session
eavesdropping.
---
As to "universal agreement", the suggestion put forth to
have a "security package", or to use (putative) "security
profiles" and make them more visible in the install process,
have neither had one serious objection.
The only thing I have heard that borders on an objection
is the idea that there might be coding involved.
I really have no problem with the "you want it, then you
write the code to make it a non-default option" ("bell the
cat") which has historically been the position of the FreeBSD
project on controversial topics like this one.
---
So, any objection to:
The people who want it, write the code to make it an
option that is off by default, so that the rest of
the world who hates the idea can ignore it.
???
There's always the:
Make it on by default later.
Which is how most of these undesirable things sneak in under
the radar.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
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?200010120136.SAA12021>