From owner-freebsd-arch Fri Feb 16 10: 4:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3729337B4EC for ; Fri, 16 Feb 2001 10:04:24 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1GI2Rh59420; Fri, 16 Feb 2001 13:02:27 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Feb 2001 13:02:27 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: List of things to move from main tree to ports (was Re: Wish List (was: Re: The /usr/bin/games bikeshed again)) In-Reply-To: <200102161741.f1GHf0A97803@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Feb 2001, Matt Dillon wrote: > Well, lets at least get rid of the ones that don't cause controversy > (I'd like telnet to stay too.. I use it all the time for debugging > things like sendmail). > > I agree completely in regards to Kerberos IV. Nobody in their right > mind should be using it any more so it should definitely become a port. The problem with Kerberos is that it requires substantial integration into base system code that is very security-sensitive. If you move KerberosIV to a port without some form of integrating it into the base system while using base system {telnetd,ftpd,...} then people who do run Kerberos will suffer a great deal. My hope would be that we'd keep supporting KerberosIV through the end of the 4.x branch, and make KerberosV be the supported Kerberos on 5.0-RELEASE, and have KerberosIV be a port. Unfortunately, PAM cannot provide the level of integration necessary at this point. > * All games except fortune > * UUCP Sadly, this one is still controversial. See below. > * Kerberos IV > > The more controversial ones: > > * rdist > * rmt > * rcp, rlogin, rsh > > Extremely controversial: > > * telnet (i.e. its too useful to have around for other purposes) > > The main issue with removing something like rcp or rsh is that, by > default, our openssh is not compiled with the 'none' cipher, so it's > impossible to use it when non-encrypted data content is desired. Sometimes > speed is more important then encryption. (I dont use rcp or rsh myself, > but while at BEST I had on ocassion needed to use 'ssh -c none' and that > required recompiling ssh). It seems to me that moving things off into ports is to some extent undesirable, as the ports collection is intended to adapt third-party code to the FreeBSD environment, and generate binary installs. It's not intended to allow more loose bundling of code that has a local maintainer. I think a logical next step on a number of these components is not to make them a port, but to make them not be part of the base "default" distribution. I.e., make UUCP a distribution of its own, and move from having a NO_UUCP to having a BUILD_UUCP flag in make.conf. There is also, I think, a strong argument towards avoiding making things be a port when they are substantially useful as part of the base system. One of the things that has characterized FreeBSD is a reasonable default install that looks like you'd expect UNIX to look. Regardless of the success of SSH, telnet is something that many administrators use daily to build TCP connections for testing mail, connecting to routers and boxes on local area networks, etc. Also, telnet contains SRA support, as well as Kerberos support, meaning that it is really not accurate to describe it purely as an insecure application. As much as I love SSH, it also has a lot of poor failure modes regarding key storage, configuration files, and probably needs more coordinated maintainership and a better review process for updates. One strong argument for disabling aspects of less well maintained code in the base system is whether they constitute a security risk by existing there unused. Generally speaking, this applies to services that are enabled but not used (we've addressed this a lot better in recent iterations on rc.conf and inetd.conf), and client code in the base system that makes use of privilege models in a way that introduces risk due to complexity and failure modes (UUCP and man both come to mind), which an attacker could attempt to exploit. We've already seen setuid perl move in this direction default disabling of the setuid bit. Part of the problem here also is that we still need packageNG or sysinstallNG or whatever. We don't have a consistent and coherent way to manage the installation of optional components that are part of the base system. Moving to a nicely modular install and partitioning scheme makes sense, but creating redundant code maintenance or reducing the support level for some services is not necessarily the right solution. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message