From owner-freebsd-security  Sat Nov  2 12:05:08 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA18947
          for security-outgoing; Sat, 2 Nov 1996 12:05:08 -0800 (PST)
Received: from rover.village.org (rover.village.org [204.144.255.49])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA18936
          for <security@freebsd.org>; Sat, 2 Nov 1996 12:05:00 -0800 (PST)
Received: from rover.village.org [127.0.0.1] 
	by rover.village.org with esmtp (Exim 0.56 #1)
	id E0vJmI6-0000AR-00; Sat, 2 Nov 1996 13:03:39 -0700
To: cschuber@uumail.gov.bc.ca
Subject: Re: Vadim Kolontsov: BoS: Linux & BSD's lpr exploit 
Cc: Marc Slemko <marcs@znep.com>, security@freebsd.org
In-reply-to: Your message of "Sat, 02 Nov 1996 10:33:07 PST."
		<199611021833.KAA00905@cwsys.cwent.com> 
References: <199611021833.KAA00905@cwsys.cwent.com>  
Date: Sat, 02 Nov 1996 13:03:38 -0700
From: Warner Losh <imp@village.org>
Message-Id: <E0vJmI6-0000AR-00@rover.village.org>
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199611021833.KAA00905@cwsys.cwent.com> Cy Schubert writes:
: How about an LPRng port?  Then it would be up to each individual
: sysadmin whether to use a possibly more secure non-BSD print
: subsystem or the existing insecure print subsystem.  The port could
: disable the BSD LPR/LPD by filing off the s and x bits.  If the the
: sysadmin opts to pkg_delete the LPRng package, the BSD print
: subsystem would be re-enabled.

If you'd like to port it, go for it.  However, unless there is a good
and compelling reason to disable lpr/lpd, it won't happen.  They are
too entrenched in the BSD culture to go away by fiat.

LPRng is incompatible with LPR/LPD at the protocol level, from all
I've read.  It would be good to have it as a port, but too many places
are using lpr/lpd in mission critical applications to just junk them.

It would be a better effort, imho, to fix the security problems in
lpr/lpd than to go to a new, untried system the security aspects of
which are at best poorly understood (relative to lpr/lpd).  I know
that the OpenBSD folks have been doing security audits of the code
looking for things that could run afoul in the current lpr/lpd code.
Unless they give up as being an intractible problem, I'd be very leery
of punting on lpr/lpd altogether.

Finally, if you know of any specific weakness in lpr/lpd that hasn't
been addressed, please do let me know.  Saying it is insecure vaguely
is not as useful as being specific :-).

Warner