Ticket #1115 (closed general: fixed)
guidance from FESCO on packagekit upstream policykit change
|Reported by:||misc||Owned by:|
so over the weekend, people have notified me of a change in PackageKit 0.8.8 that basically permit to use pkcon without password to install rpm, but only if they come from a trusted repository. Basically, that's a just the same change that during F12, who caused a huge flamewar, and as we basically all know this would end tas a escalation, I decided after talking with the packager to directly go to FESCO, skipping the flamewar part ( as I think people would still just hammer the same argument as usual, and then I am sure that some journalists will relay the news to make more clicks on their web site, ie there will be nothing new or useful for the decision making process ).
Packagekit 0.8.8 is already in F19, F20 and being pushed to F18 as a update. Discussing with the upstream and packager ( Richard Hughes ), he agreed to revert this change on F18 as this was not suitable for a stable release, but would like to have a discussion for F19. And will keep the default to "no password" upstream. ( and he also asked me to open the ticket on his behalf as i proposed to do that by mail ).
The problem is the following.
Several tools use PackageKit? to install add-ons, plugins or similar software/contents. For example, Rhythmbox detect the type of a file and propose to ask to install the required gstreamer plugin if not found. Freetype detect when there is a text that requires a not installed font, etc. I think there is integration in gnome-dictionnary, bash ( command-not-found ), gnome-initial-setup, and maybe others. I can for sure imagine lots of use ( printer installation, firefox plugin installation, etc ).
However, this require to type a password to install a rpm, which seen as a annoyance by some users ( if not most ), and so by designers who try to ease the life of the users. For one notorious example, there is a rant of Linus Torvalds on the topic of asking password ( seek "opensuse Linus Torvalds rant" ), but he is not the only one, and I see everyday people being annoyed by the password proliferation ( see also Windows Vista rants all over the web ).
So people have been asking to have a password-less installation of rpm by packagekit for that kind of use case. However, due to technical constraint, this mean that all packages from the repository would be installable by someone ho can install a font, a gstreamer plugin or a dictionnary.
Now, last time this was changed, others people have been arguing that this would be insecure, citing attacks such as filling hard drive or more convoluted examples of installing on purpose insecure software to later exploit them to become root on a workstation. While some of theses attacks are IMHO too far fetched, there is lots of use case where indeed, this behavior is not a good default and should be avoided, and we would want to have a different settings. So we currently do not have a way to have a good default to satisfy all use cases of the desktop spin.
This kinda also relate to the current board discussion about default set of users, a discussion were we are struggling to reach a consensus.
This issue is a old one, and this already happened for F12, where the default was changed, but in the end, the decision to enable password-less installation was reverted by FESCO ( https://fedorahosted.org/fesco/ticket/277 )
However, the situation didn't fundamentally change since 4 years. People still hate using passwords for random stuff, and people would still loudly complain to that fix of the problem.
So there is still a tension due to technical choice between the 2 side, and either way, someone will not be satisfied, and the packagekit maintainer is in the middle, trying to fulfil contradictory requirements due to fuzzy constraints and environment.
While I didn't ask much around me, I think most people would agree that automated installation of dictionary, fonts or gstreamer plugin would likely be harmless, since that would likely not open much issues, or at least, no issues that a password prompt would have prevented. Fonts and dictionaries are just content, and I think a majority of people would install codecs anyway.
Discussing with Richard, we do not think that adding specific API in Packagekit for having a finer grained permission system would scale, as each potential user of the API would requires a PK change. I proposed to see if some SELinux integration would help ( ie, using SELinux in polkit to make sure that only trusted software can use the password-less system ), but that wouldn't work upstream for GNOME, so that wouldn't solve much either.
In the end, what I would like to see from FESCO is guidance on 2 points, as this is a technical decision to be made by the distribution :
- what to do for F19 ( short term decision )
- how to solve the issue on the long term. ( ie, satisfy the need of users who prefer to have password less installation for some specific package, and the need of users who want to have everything locked down by default )
So I would like to propose the following schema for the long term issue, replicating the SELinux idea but using groups/uid instead,
- have 1 group, called "installer-software" where we have no real users, just users for software.
- have this group being authorized to use pk to install rpm coming from trusted repository without password
- have a set of dbus daemon running system wide with a uid that is in this group ( either several separate, or just 1 )
- have software wanting fonts, dictionnary, etc ask to theses dbus services instead of pk directly
Alternatively, we could directly use a uid instead of a group, and have all the dbus enabled service to run under this uid.
So this would prevent random users from installing randoms packages thus making I think most people against the change a little bit more happy ( as there is less risk of security issues by installing a font, and less risk of serious DoS on a workstation ), this would make designers ( and so some users too ) happy, and this would decouple the API from PackageKit ( so they can evolve at different path, be updated and shipped without PackageKit ), thus making the thing more scalable.
comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 2 years ago by mitr
comment:18 follow-up: ↓ 19 Changed 2 years ago by kevin
- Status changed from new to closed
- Resolution set to fixed
comment:27 Changed 2 years ago by mattdm
- Status changed from closed to reopened
- Resolution fixed deleted
comment:28 Changed 2 years ago by mattdm
- Status changed from reopened to closed
- Resolution set to fixed