HP Linux Imaging and Printing System (HPLIP) 2.7.10 Release

[Hosszu, John]

HPLIP 2.7.10 - This release has the following changes:

1. Made a change to 55-hpmud.rules so that it also works for SUSE 10.3. This rule is still backward compatible with older udev based distros.
2. Applied patch for issue CVE-2007-5208 (hpssd command injection)
3. Added detection for Reportlab 2.x in hp-check and hp-sendfax
4. Fixed defect (Traceback information displays when right-click the picture icon in the "Unload Photo Card" window.)
5. Added new icons for Officejet J3600 and Officejet J5500
6. Fixed defect (Chinese: The Default button in the print setting tab always invalid when configure the parameter of Page Orientation.)
7. Fixed defect (The printer will be replaced by adding another printer with the same name when setting up the printer.)
8. Added -q/--lang= to hp-setup
9. Fixed defect (Hplip installion process hangs up at "PRINTER SETUP" if select no GUIs during custom installion.)
10. Fixed defect (Chinese: Date information in the status tab of toolbox is not localized correctly.)
11. Added syslog "loading firmware" message to plugin udev files.
12. Some improvements/fixes to LaserJet status
13. Added -q/--lang to hp-unload, hp-sendfax, and hp-makecopies
14. Cleaned up some code in hpaio.
15. Updated APDK label in bootstrap
16. Cleaned up lj10xx ppds
17. Added support for the following new printer(s):

- HP Officejet Pro K8600 (DJGenericVP)
- HP Photosmart C4380 Series (DJGenericVP)
- HP LaserJet 1018 (LJZjsMono w/plug-in)
- HP LaserJet 1020 (LJZjsMono w/plug-in)
- HP LaserJet 1022 (LJZjsMono w/plug-in)
- HP LaserJet 1022n (LJZjsMono w/plug-in)
- HP LaserJet 1022nw (LJZjsMono w/plug-in)
- HP Deskjet 550C (DJ540)

HPLIP 2.7.10 - Known Issues with Localization (L10N) and Internationalization (I18N):

1. Non-Latin1 characters (Chinese, Russian, etc) cannot be used in the following locations: Coverpage information (hp-sendfax), command paths (hp-toolbox), photocard unload paths (hp-unload), fax header information (hp-toolbox), file print paths (hp-print), and file fax paths (hp-sendfax).
2. The date infomation in the status tab of HP Device Manager (hp-toolbox) may not have the correct format for the current locale.
3. Non-Latin1 characters (Chinese, Russian, etc) cannot be used for any command line utility as user input or command line argument.

[Johannes Meixner]

Hello,

1. Made a change to 55-hpmud.rules ...

I do not understand why there is OWNER="lp" in 55-hpmud.rules.

When the owner is lp, then any CUPS filter script or backend
can change the permissions as it likes, for example via
http://www.cups.org/str.php?L790

With the default MODE="0666" there is not much to change for
a possible attacker but think about that the admin may have
specified a more restrictive mode but forgot to also change
the owner to root.

To be more on the safe side, I would like to have
OWNER="root", GROUP="lp", MODE="0666" by default for openSUSE.

Is there any functionality which does no longer work
out of the box if OWNER="root"?


For MODE="0666" the crucial question is whether or not
it is possible that another user (e.g. someone who is logged in
from remote) can somehow eavesdrop when a (confidental) document
is printed or scanned.

Is eavesdropping somehow possible with MODE="0666"?
...

- HP LaserJet 1018 (LJZjsMono w/plug-in)
- HP LaserJet 1020 (LJZjsMono w/plug-in)
- HP LaserJet 1022 (LJZjsMono w/plug-in)
- HP LaserJet 1022n (LJZjsMono w/plug-in)
- HP LaserJet 1022nw (LJZjsMono w/plug-in)

For openSUSE I provide only HPIJS as package hpijs-standalone.
Currently this package contains only /usr/bin/hpijs and some
documentation.

I build it via
------------------------------------------------------------
./configure --prefix=/usr \
--libdir=%_libdir \
--disable-foomatic-xml-install \
--disable-foomatic-ppd-install \
--disable-doc-build \
--enable-hpijs-only-build
make
------------------------------------------------------------

Assume the user has a ZJStream printer and he has somehow
manually downloaded the necessary plug-in.

Would then the plain /usr/bin/hpijs work for his ZJStream printer?

I.e. would the plain /usr/bin/hpijs autmatically find his plug-in
and use it or is additional software needed and in case of the
latter which additional software from HPLIP is needed?


By the way:
There is nothing about the new LJZjsMono device class at
http://hplip.sourceforge.net/tech_docs/device_classes.html
or about the new plug-in mechanism at
http://hplip.sourceforge.net/tech_docs/hpijs.html


Kind Regards
Johannes Meixner

[Tim Waugh]

Post by Johannes Meixner

1. Made a change to 55-hpmud.rules ...

I do not understand why there is OWNER="lp" in 55-hpmud.rules.
When the owner is lp, then any CUPS filter script or backend
can change the permissions as it likes, for example via
http://www.cups.org/str.php?L790
With the default MODE="0666" there is not much to change for
a possible attacker but think about that the admin may have
specified a more restrictive mode but forgot to also change
the owner to root.
To be more on the safe side, I would like to have
OWNER="root", GROUP="lp", MODE="0666" by default for openSUSE.

For a solution to this problem that does not allow arbitrary write
access, but instead constrains access to (a) the print spooler and (b)
the console user(s), please see my write-up of how we approached HPLIP
device permissions for Fedora 8:

http://cyberelk.net/tim/2007/10/04/hplip-device-permissions-with-consolekit/

Tim.
*/

[Johannes Meixner]

Hello,

Post by Tim Waugh
For a solution to this problem that does not allow arbitrary write
access, but instead constrains access to (a) the print spooler and (b)
the console user(s), please see my write-up of how we approached HPLIP
http://cyberelk.net/tim/2007/10/04/hplip-device-permissions-with-consolekit/

Looks similar to our "resmgr" which we use currently but only
for HP all-in-one devices, see in

http://sourceforge.net/mailarchive/message.php?msg_name=Pine.LNX.4.64.0707040850200.22081%40nelson.suse.de

in the section regarding "controllable permissions" item c).


For the upcomming openSUSE 11.0 I will use "resmgr" also for
plain printers (to make device status available for the "console user")
and fortunately we now have the USB device IDs so that it is possible
to have it set up correctly out of the box.


But I still wonder if perhaps mode 0666 is o.k. for HP USB
printers and all-in-one devices if eavesdropping is not
possible with MODE="0666".

E.g. because for each device IO the hpmud library tries to open it
only exclusively so that eiher an existing eavesdropper is noticed
and hpmud would not open it, or after the exclusive open via hpmud
no additional open by an eavesdropper is possible.


Kind Regards
Johannes Meixner

[Suffield, David]

Hi Johannes,

Post by Johannes Meixner

1. Made a change to 55-hpmud.rules ...

I do not understand why there is OWNER="lp" in 55-hpmud.rules.
When the owner is lp, then any CUPS filter script or backend
can change the permissions as it likes, for example via
http://www.cups.org/str.php?L790
With the default MODE="0666" there is not much to change for
a possible attacker but think about that the admin may have
specified a more restrictive mode but forgot to also change
the owner to root.
To be more on the safe side, I would like to have
OWNER="root", GROUP="lp", MODE="0666" by default for openSUSE.
Is there any functionality which does no longer work out of
the box if OWNER="root"?

Actually I made the OWNER="lp" change in 2.7.9 not 2.7.10.

Changing OWNER="lp" to OWNER="root" is a valid change. The only reason I
changed it was I thought OWNER="lp" would be more secure than
OWNER="root" with MODE="0666".

I don't claim to be a security expert, but if OWNER="root" is not a
problem I would be happy to change it.

Post by Johannes Meixner
For MODE="0666" the crucial question is whether or not it is
possible that another user (e.g. someone who is logged in
from remote) can somehow eavesdrop when a (confidental)
document is printed or scanned.
Is eavesdropping somehow possible with MODE="0666"?

Given only one process can claim the USB interface for reading or
writing, and claiming the interface is arbitrated by the kernel, I would
say no other process could snoop the print job or scan job.

Setting the permissions to MODE="0666" is strictly the default for hplip
tar ball install. We have a lot of customers performing the tar ball
install so this makes it much easer from a customer support standpoint
with all the different distributions.

I would be glad to support a less permissive user policy with "resmgr"
or "ConsoleKit", but these are Suse and Fedora specific solutions
(right?). So for now I'm happy to let you set your own user policies in
your binary packages.

I will let Raghu answer your hpijs ZJStream questions.

-dave

Post by Johannes Meixner
...

- HP LaserJet 1018 (LJZjsMono w/plug-in)
- HP LaserJet 1020 (LJZjsMono w/plug-in)
- HP LaserJet 1022 (LJZjsMono w/plug-in)
- HP LaserJet 1022n (LJZjsMono w/plug-in)
- HP LaserJet 1022nw (LJZjsMono w/plug-in)

For openSUSE I provide only HPIJS as package hpijs-standalone.
Currently this package contains only /usr/bin/hpijs and some
documentation.
I build it via
------------------------------------------------------------
./configure --prefix=/usr \
--libdir=%_libdir \
--disable-foomatic-xml-install \
--disable-foomatic-ppd-install \
--disable-doc-build \
--enable-hpijs-only-build
make
------------------------------------------------------------
Assume the user has a ZJStream printer and he has somehow
manually downloaded the necessary plug-in.
Would then the plain /usr/bin/hpijs work for his ZJStream printer?
I.e. would the plain /usr/bin/hpijs autmatically find his
plug-in and use it or is additional software needed and in
case of the latter which additional software from HPLIP is needed?
There is nothing about the new LJZjsMono device class at
http://hplip.sourceforge.net/tech_docs/device_classes.html
or about the new plug-in mechanism at
http://hplip.sourceforge.net/tech_docs/hpijs.html
Kind Regards
Johannes Meixner

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[Johannes Meixner]

Hello David,

Post by Suffield, David
Changing OWNER="lp" to OWNER="root" is a valid change. The only
reason I changed it was I thought OWNER="lp" would be more secure
than OWNER="root" with MODE="0666".
I don't claim to be a security expert, but if OWNER="root" is not
a problem I would be happy to change it.

I am also no security expert.
That's why I follow any advise from our security team.

As far as I understand it, traditional security in Unix/Linux
(i.e. without additional stuff like AppArmor or SELinux)
is done by a separation by using different user accounts.

Here changing the device file permissions is separated
from using the device file (under the given permissions)
by using different user accounts for the device file owner
(the only user account - except "root" - which can change
the permissions) and for those who should only use it.

Therefore OWNER="johndoe", GROUP="lp", MODE="0666"
would also do this separation (now only "johndoe" and "root"
can change the permissions) but usually it is not desired
that "johndoe" can change device file permissions so that
I simply use the "default system owner" which is "root".

In my HPLIP 2.7.10 packages on
http://download.opensuse.org/repositories/home:/jsmeix/
I have
OWNER="root", GROUP="lp", MODE="0666"

Let's simply wait and see if there are any complaints
because of it.


Another example how the separation implements security:

The cupsd runs under a differnt user than the filters and
backends so that filters and backends cannot change internal
settings (i.e. the config) of the cupsd.

Again if cupsd would run as user "johndoe" and filters and
backends would run as user "lp" the separation would exist.

But unfortunately traditional Unix/Linux does not allow
that a normal user "johndoe" can open ports below 1024
(but cupsd must open port 631) and/or that a normal user
can switch automatically (i.e. without a password dialog)
to user "lp" to run the filters and backends as user "lp".
In particular because of the latter, cupsd must run
all the time as root.

Post by Suffield, David

Post by Johannes Meixner
For MODE="0666" the crucial question is whether or not it is
possible that another user (e.g. someone who is logged in
from remote) can somehow eavesdrop when a (confidental)
document is printed or scanned.
Is eavesdropping somehow possible with MODE="0666"?

Given only one process can claim the USB interface for reading or
writing, and claiming the interface is arbitrated by the kernel, I would
say no other process could snoop the print job or scan job.

Could you give me some more details what hpmud does to open the
device file so that I can let our security team have a look at it
or should they simply check all the files in io/hpmud/?

Post by Suffield, David
Setting the permissions to MODE="0666" is strictly the default for hplip
tar ball install. We have a lot of customers performing the tar ball
install so this makes it much easer from a customer support standpoint
with all the different distributions.

I recommend not to sacrifice "reasonable security by default"
for "make it easy for the customer" because in particular your
unexperienced customers can only blindly trust you that your
software doesn't do any harm or allow that harm can happen.
You may have a look at
http://en.wikipedia.org/wiki/Three_Laws_of_Robotics

It depends on what you think is worth more:
The reputation that HP is a company which can be trusted
or blindly make everything easy for the user.

If your software causes harm and a public discussion happens,
it would not help you to say "root is required to install it".

For example have a look at what Samsung did in their attempt
to make everything easy for the user with their driver.
I don't know how big the damage is for Samsung but at least
they are now known as an example for insecure drivers from
manufacturers - in contrast to real free-software drivers
where at least more people have had a look before it hits
unexperienced customers.


By the way:
It is such a pleasure that we can discuss such issues directly with
the people at the manufacturer on a public accessible mailing list
to find step by step the best possible solution - i.e. the right
balance between "reasonable security by default" and
"make it easy for the customer".


Kind Regards
Johannes Meixner

[Suffield, David]

Hi Johannes,

Post by Johannes Meixner
As far as I understand it, traditional security in Unix/Linux
(i.e. without additional stuff like AppArmor or SELinux) is
done by a separation by using different user accounts.
Here changing the device file permissions is separated from
using the device file (under the given permissions) by using
different user accounts for the device file owner (the only
user account - except "root" - which can change the
permissions) and for those who should only use it.
Therefore OWNER="johndoe", GROUP="lp", MODE="0666"
would also do this separation (now only "johndoe" and "root"
can change the permissions) but usually it is not desired
that "johndoe" can change device file permissions so that I
simply use the "default system owner" which is "root".

Good analogy - device file permissions for ownership is separate from
device file permissions for using the device file (ie: group and other).
Only the device owner has the right to change device file permissions.

I plan on changing the OWNER="lp" to OWNER="root" in the 55-hpmud.rules
file.

Post by Johannes Meixner

Post by Suffield, David

Post by Johannes Meixner
For MODE="0666" the crucial question is whether or not it is
possible that another user (e.g. someone who is logged in from
remote) can somehow eavesdrop when a (confidental) document is
printed or scanned.
Is eavesdropping somehow possible with MODE="0666"?

Given only one process can claim the USB interface for reading or
writing, and claiming the interface is arbitrated by the kernel, I
would say no other process could snoop the print job or scan job.

Could you give me some more details what hpmud does to open
the device file so that I can let our security team have a
look at it or should they simply check all the files in io/hpmud/?

Yes, all the hplip i/o code is in io/hpmud.

For usb all i/o goes through libusb/usbfs. All read/writes to any
end-point require a claim_usb_interface(). Once the interface is claimed
all i/o to that interface is exclusive (ie: 7/1/2).

Parallel i/o is similar. All hpmud parallel i/o goes through
ppdev/parport. Before any i/o can take place PPCLAIM will claim
exclusive access to the port (ie: /dev/parport0).

-dave

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[Johannes Meixner]

Hello David,

Post by Suffield, David

Post by Johannes Meixner
Could you give me some more details what hpmud does to open
the device file so that I can let our security team have a
look at it or should they simply check all the files in io/hpmud/?

Yes, all the hplip i/o code is in io/hpmud.
For usb all i/o goes through libusb/usbfs. All read/writes to any
end-point require a claim_usb_interface(). Once the interface is claimed
all i/o to that interface is exclusive (ie: 7/1/2).
Parallel i/o is similar. All hpmud parallel i/o goes through
ppdev/parport. Before any i/o can take place PPCLAIM will claim
exclusive access to the port (ie: /dev/parport0).

I filed
https://bugzilla.novell.com/show_bug.cgi?id=336658
so that our security team can have a look.

Let's see what their advice is.


Kind Regards
Johannes Meixner