Date: Wed, 11 Oct 2000 15:28:24 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Terry Lambert <tlambert@primenet.com> Cc: Marius Bendiksen <mbendiks@eunet.no>, Matt Dillon <dillon@earth.backplane.com>, arch@FreeBSD.ORG Subject: Re: cvs commit: src/etc inetd.conf Message-ID: <Pine.NEB.3.96L.1001011152301.44391F-100000@fledge.watson.org> In-Reply-To: <200010110547.WAA11724@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Oct 2000, Terry Lambert wrote: > > I like the idea of an "anal" package, though... > > Specifically, it is exactly the sort of thing I would install > _after_ I was sure everything was working in SSH-land, rather > than relying on the "automatic" process not failing. People > may want to consider that it is more security conscious to use > an out-of-band mechanism to establish the key set, anyway. I should clarify my position here: I'm not against tightening down the defaults, I'm against making it harder for headless systems to be configured due to tightening down the defaults in un-useful ways. I think the best answer to this is improved configurability: rather than simply disabling all services, provide some options (that can be scripted for headless installs) as to what is enabled and disabled by default. The easiest option is to provide a big great knob enabling and disabling inetd with a moderately useful set of things turned on in inetd.conf -- telnet, ftp, rlogin, etc. When asking the user if they want it enabled, be relatively specific in describing what it provides by default, noting that local configuration changes will be relevant. If inetd is disabled by default, that satisfies concerns about being safe out of the box (a concern I can sympathize with), and when the user chooses to enable it, they get a set of services with approximately the same security properties: flexible authentication, low levels of cryptographic protection when not used with Kerberos. If someone wants to build an automatic inetd.conf frobber (dcs had a libconf, I believe, that was capable of handling the backend of that process), great. You'll find, of course, that this closely resembles what we already have available. :-) Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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.NEB.3.96L.1001011152301.44391F-100000>