Bug 443338 - Right to install packages should imply right to update system
Right to install packages should imply right to update system
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-20 17:26 EDT by Jay Turner
Modified: 2015-01-07 19:16 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-18 04:53:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lubomir Kundrak 2008-04-20 17:26:06 EDT
Description of problem:

When the system policy allows the user to install packages, he shouldn't be
asked for a password when he chooses to update the system.

(By the way, is it possible to limit the privilege to install packages to
packages signed with known gpg keys only?)
Comment 1 Richard Hughes 2008-04-20 20:03:46 EDT
>shouldn't be asked for a password when he chooses to update the system

I don't think it's possible to infer an auth with PolicyKit - davidz?

>install packages to packages signed with known gpg keys only

Not yet, but it's in progress. See #440060
Comment 2 David Zeuthen 2008-04-20 20:45:45 EDT
(In reply to comment #1)
> >install packages to packages signed with known gpg keys only
> 
> Not yet, but it's in progress. See #440060

Right, this is important to fix. Users should never ever be able to retain
authorizations to install packages not signed by a trusted key. 

> >shouldn't be asked for a password when he chooses to update the system
> 
> I don't think it's possible to infer an auth with PolicyKit - davidz?

Sure it is. You can just check for both authorizations in your mechanism's
Update() method. Do remember the reverse is certainly not true (right to update
does not imply right to install) and would be a security bug if it did. 

Also PolKitGnomeAction would need to support feeding it with more than one
authorization, e.g.

http://hal.freedesktop.org/docs/PolicyKit-gnome/PolKitGnomeAction.html#PolKitGnomeAction--polkit-action

currently only takes a single action. And you'd need to return two actions in
the D-Bus exception if the caller lacks both of these. As such, I don't think
this is interesting to address because it would complicate some pretty
security-critical code paths for little gain.

And once bug 440060 is resolved updating the system with packages signed by a
trusted key shouldn't need to require any password by default. So once this is
resolved no ordinary setups will run into this.

Of course once bug 440060 is resolved you may consider just collapsing update
and install into a single action. Because I can only think of contrived examples
where you want a user to be authorized for one but not the other. Can you think
of any?

Anyway, it's normally always a good idea to keep the number of actions low to
avoid corner cases like the one reported here. Also to avoid confusing users /
sysadmins and generally keep the security sensitive codepaths simple. Less is
more. Etc. etc.. Ideally you'd have only actions

 install
 install-untrusted
 manage-gpg-keys
 manage-repositories

where only the first one can be retained by the user.
Comment 3 Richard Hughes 2008-05-06 13:15:56 EDT
>I can only think of contrived examples where you want a user to be authorized
for one but not the other. Can you think of any?

Well, if you lump this together you don't get the "right" titles and messages on
the policykit auth prompt - but other than that I agree with you.
Comment 4 Bug Zapper 2008-05-14 05:48:53 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Richard Hughes 2008-08-18 04:53:13 EDT
I've fixed this in 0.3.0 which should be in rawhide today.

Note You need to log in before you can comment on or make changes to this bug.