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
