Date: Fri, 7 Jul 2000 11:17:33 -0700 (PDT) From: papowell@astart.com To: Cy.Schubert@uumail.gov.bc.ca, papowell@astart.com Cc: andrews@technologist.com, arch@FreeBSD.ORG, sheldonh@uunet.co.za, will@almanac.yi.org Subject: Re: was: Bringing LPRng into FreeBSD? Message-ID: <200007071817.LAA24199@h4.private>
next in thread | raw e-mail | index | archive | help
> From Cy.Schubert@uumail.gov.bc.ca Thu Jul 6 19:48:34 2000
> From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
> To: papowell@astart.com
> cc: sheldonh@uunet.co.za, andrews@technologist.com, arch@FreeBSD.ORG,
> will@almanac.yi.org
> Subject: Re: was: Bringing LPRng into FreeBSD?
> Date: Thu, 06 Jul 2000 19:46:53 -0700
>
> In message <200007060333.UAA23827@h4.private>, papowell@astart.com
> writes:
> > > From sheldonh@axl.ops.uunet.co.za Mon Jun 26 02:46:32 2000
> > > From: Sheldon Hearn <sheldonh@uunet.co.za>
> > > To: arch@FreeBSD.ORG
> > > cc: papowell@astart.com
> > > Subject: Re: was: Bringing LPRng into FreeBSD?
> > > Date: Mon, 26 Jun 2000 11:46:23 +0200
> > >
> > >
> > > Could someone just enumerate the advantages of importing LPRng? It
> > > seems to be a package which can me made to do everything FreeBSD's lpr
> > > can do, but it does not seem to be a superset of FreeBSD's lpr. This
> > > means that there is a cost associated with bringing it in as a
> > > replacement.
> > >
> > > Are we sure that the cost is justified? Is it so much better than the
> > > existing lpr that having it available as a port is "not enough"?
> > >
> > > I have no stsrong opinion one way or the other, but I do get the feeling
> > > that this thread has skipped an important issue, instead focusing on
> > > licensing. This looks like a little cart before horse.
> >
> > I started the work on LPRng with one major goal in mind: make it
> > secure when used in a Computer Science Laboratory. For example,
> > LPRng does not need to run SETUID root unless compatibility with
> > vintage or legacy printing systems such is required. The code is
> > extremely paranoid about all buffer sizes, string lengths, and so
> > forth, and goes to great lengths to check for various know hacker
> > attacks as well. In addition, there are facilities to use
> > encryption and Kerberos based authentication to prevent abuse
> > of the printing system.
>
> An additional degree of security can be obtained by removing the setuid
> bit from Berkeley lpr and running it setgid "lpr". One could even turn
> off the setgid bit and make the lpd spool directories world writable
> with the sticky bit turned on. Of course this comes at the price of
> reduced functionality, e.g. lpr -r won't work any more.
>
> I'd suggest making lpr setgid "lpr" or running LPRng "secured" and
> providing instructions or a script for sysadmins to enable/disable the
> additional functionality by turning on/off the setuid bit.
>
> Posix.1e will go a long way to mitigate some of these issues and may
> make much of this moot.
>
>
> Regards, Phone: (250)387-8437
> Cy Schubert Fax: (250)387-5766
> Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca
> Open Systems Group, ITSD, ISTA
> Province of BC
If you look in the LPRng-HOWTO, there is a small section on security.
There are a couple of things that the classical print spooler does that
makes providing 'security out of the box' and 'compatibility with RFC1179'
and 'backwards compatibility with vintage print servers' and 'compatibility
with Commercial Unix Systems' really nasty.
Just for your enjoyment, let me provide a short essay on the
Joys of RFC1179 (LPD Print Protocol).
The big problem with RFC1179 (LPD Print Protocol) is that the
listening port (515) is 'reserved', AND according to RFC1179,
the originating port for connections must be 721-731 (i.e. -
'reserved'). This has some nasty implications for security.
If you must have OUTGOING compatibility with other LPD print
spoolers, then, in the immortal words of Steve Bellovin, "You have
a problem." You cannot surrender root privileges UNLESS you have
the 'open priv port for listening' and 'bind to priv port for
sending' capability, which as far as I know is only available in
capability based permissions system.
Next, you need to decide on how you are going to deliver output to
your printers. If you are forced to use the RFC1179 (LPD) protocol
because the printer manufacturer or network interface manufacturer
decided that this was the only TCP/IP method they were going to
support, then you are forced to keep root permissions and cannot
drop them.
If you can use the 'appsocket' protocol supported by the vast
majority of printers now EXCEPT Apple (Hint: tell Apple you want
this facility BACK) then you stand a fighting chance of making a
fairly reliable network. The 'appsocket' protcol basically says
that the printer will listen on a port (usually 9100 on HP JetDirect
boxes), and deliver the input on this port to the print engine.
In addition, you can usually configure this so that only connections
from a specified IP address are accepted. Another alternative is
to use the IPP protocol to deliver jobs to the printer. This is
fairly new and is not supported on all printers yet. The real
advantage of this protocol is that you do NOT need to originate a
connection from a reserved port.
If you do NOT require INCOMING compatibility with print spoolers
other than LPRng, then you can have the LPD server started as a
non-privileged user, and listen for connections on some port other
than 515. This means that you NEVER run as root and greatly reduces
the possibilities that a buffer overflow, etc., can cause problems.
If you DO require INCOMING compatibility, then you can start as
the lpd server as root, bind to port 515, and then drop root
permissions using setuid(daemon). This is the undocumented option
'drop_root', which has the default value 'NO'. when I had it
documented and set to 'YES' people would use this option and then
discover that they could not connect to Solaris, HP Jet Direct
boxes, etc. After 100 email messages about this 'Bug' I ripped
this option out of the distribution. Sigh...
<digression>
Actually, this is NOT quite true. There are several broken
implementations of TCP/IP stacks that have problems with dropping
root permissions. On these systems if you open a socket as ROOT
(euid 0), when you do 'talk = accept()' on the listening socket
YOU CANNOT SET THE SOCKET OPTIONS on the 'talk' socket. This has
the side effect that you cannot set the SO_LINGER, SO_REUSE, and
other options that allow you do control other actions. More
important is that you cannot use fcntl() on the socket either, and
put it into blocking or non-blocking mode. Grrrr.... I have always
wondered who was the bright eyed genius who thought that this was
a good idea... :-)
</digression>
The only way to determine that you have this problem is to write
a small test program that tests this out, and if this is the case
you have to NOT drop root, or to do this in your lpd server each
time it starts up.
So we have dealt with the server. What about the clients? If you
do NOT require FULL compatibility with RFC1179, then simply install
them as ordinary applications. However, some people will whine at
this and say that LPRng is supposed to be 'fully RFC1179' and that
they cannot use this with Solaris/HP/Vax/.../JetDirect systems,
and they want it back. So it is an option.
As you probably have guessed, I have been through this problem
several times, and each time I have had nothing but headaches.
Summary:
LPD Server
Safest: run as daemon, use non-privledged port
- incompatible with anything but LPRng
Next Safest: start as root, drop root after listening
socket created
- only compatible with INCOMING connections
Evil But Necessary: start as root, run with root
LPR, LPRM,
Safest: run as user, not setuid
- incompatible with LPD that insists on connections
originating from Priv Port (Solaris, etc.)
Evil But Necessary: run setuid root
Patrick ("Did I mention permissions on devices? No? Well,
enough headaches for now") Powell
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?200007071817.LAA24199>