Re: [HPLIP-Devel] HP Linux Imaging and Printing System (HPLIP) 2.7.10 Release
Hello David, On Oct 24 18:58 Suffield, David wrote (shortened): 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 -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex - 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/ ___ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel
Re: [HPLIP-Devel] HP Linux Imaging and Printing System (HPLIP) 2.7.10 Release
Hello David, On Oct 23 21:31 Suffield, David wrote (shortened): 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. 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/? 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 -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex - 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/ ___ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel
Re: [HPLIP-Devel] HP Linux Imaging and Printing System (HPLIP) 2.7.10 Release
Hi Johannes, 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. 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/ ___ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel
Re: [HPLIP-Devel] HP Linux Imaging and Printing System (HPLIP) 2.7.10 Release
Hi Johannes, HPLIP 2.7.10 - This release has the following changes: 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. 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 17. Added support for the following new printer(s): ... - 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 - 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/ ___ HPLIP-Devel mailing list HPLIP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hplip-devel
