From owner-freebsd-arch Wed Oct 11 18:36:45 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 8650637B502 for ; Wed, 11 Oct 2000 18:36:42 -0700 (PDT) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id SAA17509; Wed, 11 Oct 2000 18:33:51 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpdAAAylaWcI; Wed Oct 11 18:33:42 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA12021; Wed, 11 Oct 2000 18:36:25 -0700 (MST) From: Terry Lambert Message-Id: <200010120136.SAA12021@usr09.primenet.com> Subject: Re: cvs commit: src/etc inetd.conf To: drosih@rpi.edu (Garance A Drosihn) Date: Thu, 12 Oct 2000 01:36:25 +0000 (GMT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), dillon@earth.backplane.com (Matt Dillon), arch@FreeBSD.ORG In-Reply-To: from "Garance A Drosihn" at Oct 11, 2000 07:25:20 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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