Bug#526854: hal: HAL should not require PolicyKit
severity 526854 wishlist tags 526854 wontfix thanks Fredrik Tolf wrote: Package: hal Version: 0.5.12~git20090406.46dc48-2 Severity: important I think that it is a bad thing that HAL started depending on PolicyKit in the latest versions. PolicyKit introduces a whole new, parallel security system, and it does not seem to be well-known how it works or how to properly administer it (I, for one, certainly don't know how it works, at least). Therefore, it may introduce security holes unknown to the maintainer of some systems. In particular seeing how HAL is required by so many things (GNOME and KDE, for example), it may even install PolicyKit without the administrator knowing about it (installing GNOME or KDE pulls in so many other packages anyway that it might be hard to spot PolicyKit among them; I almost missed it in the latest dist-upgrade). I have not researched it in detail yet, so I don't really know if it's a good So you are basing your request on FUD? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 09:52 +0200, Michael Biebl wrote: I have not researched it in detail yet, so I don't really know if it's a good So you are basing your request on FUD? I don't think so. What I meant by not researching was whether the solution of splitting it into two packages would be plausible. As for my wider argument, I may be wrong somewhere along the line, but please correct me if that is so. My argument is this: First, as far as I know, PolicyKit is essentially a system for granting privileges to a user which he would not have without it. In other words, depending on the configuration of PolicyKit, a user may be allowed to do things he would not be allowed to without it [see note 1]. Second, the configuration and operation of PolicyKit is not well-known, unlike normal Unix security. Third, Debian previously used ordinary Unix groups to assign various HAL-related privileges to users. Everyone known how Unix groups work; if a user wasn't a member of any particular groups, he would be granted no unexpected privileges. Thus, I think it is a bad idea to install PolicyKit by default: With PolicyKit, I don't even know how permissions are granted to users. I know that it's supposed to authenticate through PAM, but I have not yet found any information on how it actually authorizes the authenticated users for the various permissions it can grant. Note, also, the following remark from the PolicyKit(8) manpage: TODO: This manual page should contain a simple introduction to PolicyKit for a system administrator audience. Remains to be written. The same manpage points to /usr/share/doc/policykit for more information, but it only contains a README explaining why various policykit programs have the file modes they do, and nothing about how to administer PolicyKit itself. That is my conclusion. Please tell me if I'm wrong somewhere along the line. Fredrik Tolf -- Note 1: Parenthetical remark -- As such, PolicyKit, as a security system, differs from systems like SELinux which only remove privileges a user would otherwise have, and which therefore do not create any new vectors for doing privileged operations, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
Fredrik Tolf wrote: On Mon, 2009-05-04 at 09:52 +0200, Michael Biebl wrote: I have not researched it in detail yet, so I don't really know if it's a good So you are basing your request on FUD? I don't think so. What I meant by not researching was whether the solution of splitting it into two packages would be plausible. As for my wider argument, I may be wrong somewhere along the line, but please correct me if that is so. My argument is this: First, as far as I know, PolicyKit is essentially a system for granting privileges to a user which he would not have without it. In other words, depending on the configuration of PolicyKit, a user may be allowed to do things he would not be allowed to without it [see note 1]. Well, that is also true for the group based approach that was previously used in HAL, just much more coarse grained and less flexible and dynamic. Second, the configuration and operation of PolicyKit is not well-known, unlike normal Unix security. That basically reads, like you are missing proper documentation. Have you installed policykit-doc and read the documentation provided there (best read with devhelp)? But certainly documentation can always be improved. Third, Debian previously used ordinary Unix groups to assign various HAL-related privileges to users. Everyone known how Unix groups work; if a user wasn't a member of any particular groups, he would be granted no unexpected privileges. We invented groups like plugdev/netdev/powerdev in HAL, to control access to the HAL D-Bus service. Yet the exact meaning of those groups is very vague (or can you tell me which privileges you exactly get by being a member of e.g. group plugdev?) This is now replaced with PolicyKit. With the HAL policykit configuration file (you can inspect the HAL PolicyKit configuration with polkit-gnome-authorization), it is much clearer (and documented) what privileges are granted. Again, the group-based approach is less flexible, too coarse grained, not dynamic and not scalable. Thus PolicyKit is a definit improvement (security wise). What I miss from your arguments are solid, technical reasons, why PolicyKit is, as you put it, a bad idea. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 21:06 +0200, Michael Biebl wrote: That basically reads, like you are missing proper documentation. Have you installed policykit-doc and read the documentation provided there (best read with devhelp)? [...] We invented groups like plugdev/netdev/powerdev in HAL, to control access to the HAL D-Bus service. Yet the exact meaning of those groups is very vague (or can you tell me which privileges you exactly get by being a member of e.g. group plugdev?) [...] Again, the group-based approach is less flexible, too coarse grained, not dynamic and not scalable. Thus PolicyKit is a definit improvement (security wise). [...] What I miss from your arguments are solid, technical reasons, why PolicyKit is, as you put it, a bad idea. Based on your comments, I think you misunderstand me. I don't think PolicyKit is a bad idea, and I agree that the groups previously used were too coarsely grained and too unclear about what privileges were granted through them. What I do think is a bad idea is installing policykit by default, as a hard dependency of HAL. Even if I don't know exactly what privileges are granted through the `plugdev' group, I do know for sure that without being a member of it, no privileges at all are granted, which is something I cannot necessarily know with PolicyKit. In fact, I installed policykit-doc, as you suggested, and from reading it, it seems that it is the inidividual packages that grant privileges by default simply by installing policy files into /usr/share/PolicyKit/policy. For example, merely by having NetworkManager installed, local users would automatically be granted privilege to change networks, whereas previously, I would have to make them part of the netdev group, explicitly. My point, therefore, is that since the installation of PolicyKit grants privileges to users merely by virtue of being installed, it should not be installed automatically. If it is installed automatically, I should at least have to turn it on explicitly. Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 23:12 +0200, Fredrik Tolf wrote: What I do think is a bad idea is installing policykit by default, as a hard dependency of HAL. Just in case I wasn't clear enough, my argument is this: Without PolicyKit, I had to take explicit action in order to grant privileges to users, while with PolicyKit, I have to take explicit action in order to *not* grant privileges to users. Therefore, it should not be installed by default, since the mere act of installing it suddenly gives all my existing users new privileges, without me, the administrator, even being warned of such a thing. Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
Fredrik Tolf [2009-05-04 21:37 +]: Just in case I wasn't clear enough, my argument is this: Without PolicyKit, I had to take explicit action in order to grant privileges to users, while with PolicyKit, I have to take explicit action in order to *not* grant privileges to users. That's not an inherent property of PK vs. groups, but a matter of default configuration. E. g. the installer used to put the default user into plugdev, powerdev, etc., and users-admin (from gnome-system-tools) did similar things for a desktop user. Likewise, there are PolicyKit privileges which you don't have as an user, for good reason (like mounting an internal hard disk). The job of us as a distro is to provide a sensible default configuration which provides a good balance between security and usability. For example, it doesn't make much sense to deny access to an USB camera or scanner to an user at a local console; he has physical access to those devices, after all. On the other hand, an user logging in through ssh should arguably not have these capabilities. Thus I am very much against making PK optional. It will only aggravate the confusion, since there will be systems which use PK and some which don't. History showed that device access privileges can't be sensibly mapped to and maintained with static group membership, so we should settle to _one_ system of verifying privileges, also to be compatible with the rest of the world. To be fair, I had very similar feelings like you when I heared about PK the first time, since it seemed to be that ominous new thing which opened root holes in the background. :-) Just my € 0.02, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 23:57 +0200, Martin Pitt wrote: Fredrik Tolf [2009-05-04 21:37 +]: Just in case I wasn't clear enough, my argument is this: Without PolicyKit, I had to take explicit action in order to grant privileges to users, while with PolicyKit, I have to take explicit action in order to *not* grant privileges to users. That's not an inherent property of PK vs. groups, but a matter of default configuration. E. g. the installer used to put the default user into plugdev, powerdev, etc., and users-admin (from gnome-system-tools) did similar things for a desktop user. Both of those are special cases explicitly designed for usability with weaker security, though. I use neither. The job of us as a distro is to provide a sensible default configuration which provides a good balance between security and usability. Arguably so, but how do you define what is sensible? In my mind, PolicyKit's defaults seem sensible only for desktop setups, which aren't the only places in which HAL is being used. I've used it both in workstation-class setups and embedded special purpose setups (such as a music player computer, where I used it to detect USB storage with media files on), where it cannot reasonably be argued that local users should be granted all those privileges by default. I don't think that it should be assumed that all Debian machines are desktop machines. That's what Ubuntu is for, if you ask me. And apart from that, it would be nice to at least be *able* to create unprivileged users, which you cannot do with PK's defaults. For that matter, it is unclear what PK means by auth_admin, and I have yet found no documentation to explain it. Also, it is very unclear what one should do to avoid these sensible defaults, and if they cannot be avoided, then they aren't just defaults. For example, it doesn't make much sense to deny access to an USB camera or scanner to an user at a local console; he has physical access to those devices, after all. Quite possibly so, but I would expect to be able to leave a USB thumbdrive in the computer and not risk it being written to by any local user who you haven't given any particular privilege to otherwise read it (unlike e.g. pmount, which requires users to be part of the plugdev group). Of course he'd be able to steal it and plug it into some other computer if he has local access, but at least that would be noticed. Thus I am very much against making PK optional. It will only aggravate the confusion, since there will be systems which use PK and some which don't. Well, yeah, there will. I must admit that I don't see the problem with that. There are systems which use NIS, and other which don't. History showed that device access privileges can't be sensibly mapped to and maintained with static group membership, so we should settle to _one_ system of verifying privileges, also to be compatible with the rest of the world. Maybe, maybe not. I, for one, never had any problems with the static group membership solution, so I can't really say that history has showed that it cannot be done... Furthermore, it is precisely *because* there should be exactly one system of verifying privileges that I oppose PK, because POSIX already defines that system. With PK there are two systems, and even worse, any given user gets the union, not the intersection, of the privileges granted by each. If it were the intersection, I wouldn't object. This way, as I've said, users are getting granted privileges without me even knowing it. How about creating a special group for all users that can have privileges granted by PK? As for being compatible with the rest of the world, I resent that statement. There are different distros because not everyone wants to use the exact same thing. To be fair, I had very similar feelings like you when I heared about PK the first time, since it seemed to be that ominous new thing which opened root holes in the background. :-) I don't mean to sound offensive, but why did you change your mind? Surely it wasn't just to be like everyone else? Just my € 0.02, Since I resent the usage of fiat currency, please accept my 1 mg of gold in return. :) Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: hal: HAL should not require PolicyKit
Package: hal Version: 0.5.12~git20090406.46dc48-2 Severity: important I think that it is a bad thing that HAL started depending on PolicyKit in the latest versions. PolicyKit introduces a whole new, parallel security system, and it does not seem to be well-known how it works or how to properly administer it (I, for one, certainly don't know how it works, at least). Therefore, it may introduce security holes unknown to the maintainer of some systems. In particular seeing how HAL is required by so many things (GNOME and KDE, for example), it may even install PolicyKit without the administrator knowing about it (installing GNOME or KDE pulls in so many other packages anyway that it might be hard to spot PolicyKit among them; I almost missed it in the latest dist-upgrade). I have not researched it in detail yet, so I don't really know if it's a good solution, but I would suggest some optional bridge package which integrates HAL and PolicyKit, and which can be installed by those who want PolicyKit. Of course, it is true that the same thing may be said of HAL as well, put since the entire purpose of PolicyKit is to introduce a new layer of security and permissions, I would consider it even more dangerous. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hal depends on: ii adduser 3.110 add and remove users and groups ii dbus 1.2.12-1simple interprocess messaging syst pn hal-info none (no description available) ii libc62.9-4 GNU C Library: Shared libraries ii libdbus-1-3 1.2.12-1simple interprocess messaging syst ii libdbus-glib 0.80-3 simple interprocess messaging syst ii libexpat12.0.1-4 XML parsing C library - runtime li ii libgcc1 1:4.3.3-3 GCC support library ii libglib2.0-0 2.20.0-2The GLib library of C routines ii libhal-stora 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share ii libhal1 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share ii libsmbios2 2.0.3.dfsg-1Provide access to (SM)BIOS informa ii libstdc++6 4.3.3-3 The GNU Standard C++ Library v3 ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library ii libvolume-id 0.125-7 libvolume_id shared library ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip ii mount2.13.1.1-1 Tools for mounting and manipulatin ii pciutils 1:3.1.2-3 Linux PCI Utilities pn pm-utils none (no description available) ii udev 0.141-1 /dev/ and hotplug management daemo ii usbutils 0.73-10 Linux USB utilities Versions of packages hal recommends: ii eject 2.1.5+deb1+cvs20081104-5 ejects CDs and operates CD-Changer pn libsmbios-bin none (no description available) Versions of packages hal suggests: pn gnome-device-manager none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
