Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Feb 2001 13:02:27 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, Dag-Erling Smorgrav <des@ofug.org>, Mark Murray <mark@grondar.za>, 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))
Message-ID:  <Pine.NEB.3.96L.1010216125203.57795C-100000@fledge.watson.org>
In-Reply-To: <200102161741.f1GHf0A97803@earth.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010216125203.57795C-100000>