Re: Retiring lpr and lpd

--clx3Gmf9Dqf8DM9T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Rick Macklem wrote in <CAM5tNy67+gp=3DOBMRJaBTWXv_K3axtHZ-cb3c8Xsq5N9JxXkwY=
[email protected]>:
> Security, like safety, is not an absolute. It requires a user/sysadmin
> to evaluate the risks and make an informed decision on what to run
> and how to do it.
> --> Firewalls were invented for a reason.
>=20
> For example, if you want to secure it, NFS must be used with
> either Kerberos or TLS. but almost no one does this, due to
> administrative hassles and performance issues (encrypting/decrypting
> all those messages results in a lot of overhead).

i think there's a difference between NFS and lpd here.

with NFS, anyone with expertise in NFS is familiar with the various
issues it has (e.g., no encryption/authentication by default) and
therefore knows that to deploy NFS securely, they must use Kerberos
or TLS.  the only FreeBSD-specific knowledge they need is how those
features are configured on FreeBSD.

an administrator who is not competent in NFS may deploy NFS in an
insecure way by accident, but this is not a security vulnerability
in FreeBSD, any more than the fact that someone may deploy a website
without TLS by accident, which does not represent a vulnerability
in Apache HTTPd (or nginx, etc.).

with lpr, the situation is different, because the software itself
has known security issues that are not inherent in the lpr protocol
(to the extent that it even has a protocol) or the concept of print
spoolers in general.  that means even someone competent with print
spoolers could inadventently open security issues that are specific
to the FreeBSD implementation of lpr.

i don't have any particular opinion on whether lpr should be removed,
but i don't think this is a good argument against it.

> (For example, I use ftpd. I know there are security vulnerabilities, but
>  they are not a concern in the environment I use it in.)

ftpd, as far as i know, has no known security vulnerabilities.
there are certainly security issues with deploying ftpd with
plaintext password authentication over a clear channel, but
again, anyone competent in administration of an FTP server is
well aware of that, and ftpd could still be used to provide,
e.g., anonymous FTP access.

i did remove ftpd in 15.0, but this was not because it was insecure or
had any known vulnerabilities (as far as i'm aware); rather because the
consensus of the project was that FTP is not a very widely used protocol
nowadays and replacements for ftpd can easily be found in ports.  NFS is
again a bit different here because you couldn't just put the NFS server
in ports.  (well, i suppose you could, but ports kmods are terrible and
everyone hates them.)

--clx3Gmf9Dqf8DM9T
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSyjTg96lp3RifySyn1nT63mIK/YAUCaaQBSQAKCRD1nT63mIK/
YCHWAP9YQz5aR9dPG19BsOjcJM/54jMAC9b8KgXJLZORG/FOkwEAvnLsrP+asW3e
OljetZooUoeRNIxKRcW7xRwFZTcg9g8=
=4Fsk
-----END PGP SIGNATURE-----

--clx3Gmf9Dqf8DM9T--