needs a proper daemon or cupsys integration

This is a problem which can only be fixed upstream, so assigning to the upstream developers at HP ...

hpssd does not access the device directly. It it currently only used for two
main purposes: store a global status history for each device, and for
routing fax data from the hpfax: backend to each fax gui (that actually
access the device via the mud i/o library).

We are working on changing this design in the future, but I do not feel that
it has many inherent security concerns as no device access occurs. The race
issue is a potential problem, but even there, a second starting up hpssd
will contend for the same port, fail and exit.

-Don

On 10/4/07, Martin Pitt <email address hidden> wrote:
>
> Public bug reported:
>
> Binary package hint: hplip
>
> At the moment, the HP tools work in such a way that any tool invoked by
> the user (toolbox, scanning, etc.) forks hpssd, which then runs as that
> user. This is an absolutely broken design:
>
> * Device nodes need to be world-readable and writeable (i. e. a single big
> security hole, race conditions, etc.)
> * Multiple users race for daemon invocation.
> * User A would use the daemon of user B; B is in full control of A's work
> with the printers/scanners, etc.
>
> The best way to solve this would be a proper integration into cups, i. e
> make printing a proper cups backend which is run as lp:lp, and the
> device nodes shuold be root:lp 0660 (similar to the usb or parallel port
> backends).
>
> I appreciate that this might be too limited for the other features, such
> as scanning. For those, there needs to be a proper system-wide daemon
> hpssd which runs as lp:lp, does proper sanitation of its input, and is
> in sole control of the /dev node. To avoid big daemons like in the past,
> it shuold be very small and lightweight and can spawn the big processes
> on demand and have them time out appropriately.
>
> ** Affects: hplip (Ubuntu)
> Importance: High
> Status: New
>
> ** Changed in: hplip (Ubuntu)
> Importance: Undecided => High
>
> --
> needs a proper daemon or cupsys integration
> https://bugs.launchpad.net/bugs/149045
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Disclaimer: I have no idea about hplip, Till and I have just discussed that on IRC. However, bug 147369 seems to indicate that something in hplip needs the devices world-writeable.

mud i/o library> ah, thanks for the clarification.

Bullet 1 in the initial posting is one problem, bullet 2 and 3 another problem.

To fix bullet 1, a solution is to treat the device nodes like scanner or sound device nodes: Permissions 0660, group ownership being a group where only users who are allowed to use the desktop are members (esp. no system users, ex. group "scanner" under Ubuntu), or even better a group where only the user currently logged in on the desktop is member (PAM could change group ownership to the default group of the current desktop user, as done in Mandriva). The owner should be the "lp" user, so that the user "lp" (the user as which CUPS backends are running by default) can access the devices without being in the "scanner" (or whatever) group. This brings the device access to the same security level as standalone scanners are currently. Higher security is probably only possible by controlling the devices with a daemon like the former hpiod.

To fix 2 and 3 the daemon should either be started by an init script and kept running permanently or it should be somehow invoked with the rights of a neutral, unprivileged user. SUID "hplip" for example, and hplip should be member of appropriate groups so that hpssd has access rights only to things which it is supposed to access. The unprivileged user should not be "lp" for security reasons.

In the past (1.x in Feisty and Edgy) hplip started a "hplip"-user-run daemon. In fact, it seems the gutsy hplip install still adds the user for it. Additionally, the daemon in the 2.x version seems to be incorrectly packaged into the hplip-data package instead of hplip itself.

Kees, the hpssd daemon is not packaged incorrectly. The "hplip" package contains everything architecture-dependent, especially all binaries compiled from C code. The "hplip-data" package contains everything architecture-independent, especially all Python scripts. "hplip" depends on "hplip-data", so the installation of the latter is assured. hpssd is written in Python, so it belongs into "hplip-data". This is done to save space on the mirrors. "hplip-data" is needed only once for all architectures.

Just a comment for Martin :)

The default hplip 2.7.9 tarball install sets the device node to "world-writeable" only as a convenience to the user. We fully expect the down-stream package maintainer or admin to change this user policy to any other convention. Such as "scanner" or "lp" group membership requirements.

I really appreciate it that upstream accepts more secure
default permissions and we (i.e. Novell/Suse) have by default
rw-rw-r-- root lp

Unfortunately at least many of our users don't accept this
because only read access for normal usres is not sufficient
to query the device state from a printer (e.g. via hp-toolbox).

I really appreciate it that upstream is about to remove
the ugly daemons which are not in nice compliance how
CUPS is designed (there are bakends but no damons)
so that generic printer setup tools fail to set up a working queue
(nobody wants to have such daemons running by default just after
package installation without explicite permit by the admin).

It doesn't really help to allow rw access via a special group
because usually any user is allowed to submit a print job
so that also any user should be allowed to query the printer state.

What about the following idea:

Why not use the CUPS hp backend binary to do any device I/O?
Not as a daemon but launch it for each independent task.

A CUPS backend must be prepared to run more than once at the
same time (i.e. it must implement concurrency control).

For example when the backend runs to send a print job
to the device and now another application likes to query the
device state, the other aplication would also launch the backend
but the secondly running backend can determine that the device
is currently in use and decide what to do:

E.g. the secondly running backend could simply abort
or just wait until it is aboted by the user.

Or the first running backend might somehow provide the
current device state for the secondly running backend
(e.g. by simply writing the state into a file).

For the usual home user it would be perfectly o.k. if
the secondly running backend would simply abort with a
"deviuce currently in use - try again later" message.

If my idea could work at all, there is no need to
implement a sophisticated concurrency control now
because such kind of primitive concurrency control
(actually it is just mutual exclusion) should be sufficient.

I should have mentionend that I had in mind to
run the backend as setuid "lp" program so that
normal users get sufficient permissions implicitely
e.g. to do a device state query.

I thought that "run as lp" is sufficiently secure because
"it is just what cupsd does by default" but unfortunately
I missed that with a setuid "lp" binary there is a program
available which can be executed by any user so that
now any user might be able to do anything as user "lp"
which is not sufficiently secure to have it by default :-(

By the way:
Just add all users to the "lp" group is also not sufficiently
secure to be done by default, see
https://bugzilla.novell.com/show_bug.cgi?id=349084#c9

The access control for the non-printing functions of multi-function devices (and also stand-alone scanners) was changed in Hardy. Now it is not done any more via the "scanner" group, but the device files are now always set to be accessible by the user who is currently logged in on the desktop. So the user sitting at the desktop can scan a confidential document and other users accessing via ssh cannot see this document.

HPLIP 2.8.4 was recently released and it goes another way. It uses dbus to let processes running with different user rights communicate with each other. Components like the printer driver HPIJS, the CUPS backends, ... send status messages via dbus. This messages are caught by desktop applications as a system tray applet (which shows the status messages in pop-up bubbles) and the hp-toolbox.The hpfax CUPS backend uses dbus to send the fax to the hp-sendfax utility.

We cannot include HPLIP 2.8.4 in Hardy, as we are already after feature freeze, so it will only go into Intrepid. If you want to test already (not covered by commercial support), try the packages here (the binaries are built on Hardy amd64, for other systems rebuild the sources):

http://www.linux-foundation.org/~till/tmp/ubuntu/intrepid/hplip/

So with these changes the problems of HPLIP should be solved. I will close this bug report now.

Please report if you see new problems, especially in terms of security.

Till,
many thanks for the info!

Now it seems Ubuntu and Suse are in sync regarding the
defaults for user access which is certainly very good when
the end-user experience of different distros is very similar.

I like to learn which tool Ubunto uses to implement
the "desktop-user" access.
We use resmgr, see
http://forge.novell.com/modules/xfmod/project/?resmgr
and its HAL add-on hal-resmgr which are both free software
under "GPL v2 or later".

Another comment regarding the "scanner" group in general:

Because of the many all-in-one devices I think a separate
"scanner" group doesn't make sense to have it by default.
In openSUSE I use udev rules files for SANE and for HPLIP
which put all scanner and all HPLIP device files simply
only into the "lp" group because I think this is a reasonable
default.

In our sane-backends package I modify the
generated tools/udev/libsane.rules file as follows:
All GROUP="scanner" are replaced by GROUP="lp".
The reasons are:
There is no group "scanner" in /etc/group for openSUSE.
For all-in-one devices (e.g. "EPSON Stylus" devices)
the group must be "lp" so that the CUPS usb backend
which runs as user "lp" (who is member of the group "lp")
can send printing data to the printer unit (i.e. the printer
interface of the USB device).
It is sufficiently secure and reasonable easy to use by default
the same group "lp" for printers and scanners because both kind
of devices usually require physical user access (to get the printed
paper or to place a paper on the scanner) so that both kind of
devices should usually require the same kind of security.

Note that for hal-resmgr the wording is currently opposite:
For hal-resmgr I simply use the HAL capability "scanner"
in our HAL fdi files for all scanners and all HPLIP devices
(i.e. even for plain HP printers) to grant r/w access also
for HP printers.
For the future I think about to have the capability "lp"
also in HAL/hal-resmgr to get a consistent wording.

Hi Johannes,

Johannes Meixner [2008-04-08 10:02 -0000]:
> I like to learn which tool Ubunto uses to implement
> the "desktop-user" access.

We pretty much use the upstream solution now: ConsoleKit and
PolicyKit, and configuring hal with --enable-policy-kit
--enable-console-kit --enable-acl-management. That works fairly well
AFAICS.