Re: Draft: Security Alert Announce#1 Debian/GNU Linux

[Dan Stromberg <strombrg@hydra.acs.uci.edu>]

This got long; sorry.

LPRng compatibility issues (not necessarily exhaustive, not necessarily
show-stoppers) :

1) LPRng's printcap.5 page indicates that ":bk:" is required for strict
RFC conformance.  I am aware of only one RFC related to the BSD
printsystem, which defines the TCP/IP used, and (as I recall) nothing
about what happens on a host once the network is no longer involved. 
>From this I conclude that LPRng's ":bk:" option impacts only LPRng's
network behavior.  I found that an RFC-conformant printsystem I wrote
(which I do not really recommend for this purpose, tho it -seems- highly
secure) could not send a job to an LPRng queue until I added the ":bk:"
option into the LPRng /etc/printcap, for the relevant queue.  Amusingly,
the ":bk:" option seems to reverse the cf/df order; without ":bk:" LPRng
seems to be broken with respect to the RFC in the same sense that Ultrix
is broken - this was determined empirically, not be study of the
sources.  BTW, it is not at all difficult (in a well structured print
system) to make a printsystem handle both the RFC-order, and the
ultrix-order.

2) LPRng's printcap.5 page indicates that ":bkf:" is required to "use
Berkeley filter options".  This may help with the "of=" issue.  Also,
there is seldom any use for "of=" filters - everything can be done
nicely thru an "if=".

3) If LPRng truly has no root-owned component, then it will have a
difficult time allocating a reserved port, from which to send jobs to
existing printsystems.  Many BSD-compatible printsystems (including the
BSD system itself) requires that jobs come from a reserved port.  I
suspect LPRng's lpd does actually run as root (in some parts, but not
others - it seems to setuid and seteuid quite a bit), with non-root
clients.

My preferred approach to the situation:

	1) I think someone who follows the LPRng/plp list, should ask
           there about migration issues.  Folks there such have a
	   fairly complete notion, and will hopefully be willing and
	   able to articulate it
	2) I would want someone (I could perhaps donate some
	   time during off hours) to track down the OpenBSD fix, and
           merge that into into the debian lpr.  Was the debian lpr
	   done as patches against the upstream stuff, or is it "a
	   thing unto itself" now?

I believe we should Consider (I won't push for this, but I do want it
tossed up for discussion) compiling a version of LPRng that uses the
":bk:" and ":bkf:" (and whatever else) behaviors -by-default-.

I sincerely wish the LPRng folks had considered something like... 
Defining some alternative, required entry like "sd=", but make it "qd="
or something - and have that "qd=" presence make the defaults "the more
convenient for the long term" and the "sd=" defaults "the more
convenient for backward compatibility."

I do not recommend the system I wrote, "plpd" (not to be confused with 
Novell's "plpd"), because it implements such a minimal (but quite
workable) subset of /etc/printcap.  We use it extensively on Solaris,
but have considered moving to LPRng.

Bruce Perens wrote:
> 
> I asked Guy to expedite handling of lprng. Still, it has to get to the
> mirrors after it's installed. Sven, do you want to modify your security
> alert at all? It's not posted because the file was not available.
> 
> Does anyone want to upload a fixed "lpr"?
> 
>         Thanks
> 
>         Bruce

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com