Bug 439844 - Should not have "Remember Authorization" checked by default when installing .RPMs
Should not have "Remember Authorization" checked by default when installing ....
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
:
: 439951 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-31 14:19 EDT by Martin Jürgens
Modified: 2008-04-13 15:50 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-13 09:49:26 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 Martin Jürgens 2008-03-31 14:19:08 EDT
Description of problem:
PackageKit should not have "Remember Authorization" set by default when asking
the user for permissions to install a third party rpm.

I am seeing a little security issue in it, as the user could do it by mistake.
IMO, this should be only set by default with secure day-to-day actions like
shutting down the computer or maybe also setting the date, but not for
installing 3rd party rpms.

Another thing is that there are multiple "Add / Remove Software shortcuts",
would be nice to only have one in the Applications menu, but that's another thing :)
Comment 1 David Zeuthen 2008-03-31 16:51:53 EDT
I'm not seeing any security issues. Clearly if the system administrator wants to
allow the user to retain an authorization the only sane thing is to retain it.
That's because most users don't read these dialogs anyway.

Keep in mind that authentication dialogs are mostly always a bad idea (except
for trusted path stuff but this doesn't qualify as such) as, ideally, the user
has the authorizations he needs from the get-go. 

It is only because Fedora is a general purpose OS (e.g. we don't know a'priori
how the system is going to be used) that we err on the side of not giving a lot
of authorizations by default. (Note that this may change with targeted spins
such as the desktop live cd but is still subject to analysis, research and
implementation.)

Also remember that a sufficiently privileged user can change the defaults (e.g.
configure an action such that users can never retain an authorization for it by
authentication); see polkit-action(1) and polkit-gnome-authorization for how to
do that.

So my response is this: If you're worried about the user "accidently" keeping an
authorization then maybe you shouldn't configure it in a way that it can be
retained. Keep in mind that all this stuff depends on the security requirements
for the site you are running the system at. 

For the general purpose OS, my view is that it makes much sense to retain
authorizations for updating the system with signed software (it happens at least
once a week) while it makes little sense for stuff like formatting a system disk
(because it's such a destructive operation that happens infrequently). My point,
simply, is that it varies a lot what setting is appropriate.

How all this applies to PackageKit I will leave to the PackageKit developers. It
would probably be useful to review both the actions and their defaults [1]; I'll
try to help with that.

[1] : I don't think PackageKit makes a distinction between what action is used
if the package is signed by a trusted key vs. not. For the former we should
allow this by default, for the latter we should require the admin password and
not allow to retain such authorizations. Richard, Robin?
Comment 2 Richard Hughes 2008-04-01 06:43:03 EDT
*** Bug 439951 has been marked as a duplicate of this bug. ***
Comment 3 David Zeuthen 2008-04-01 11:31:32 EDT
(In reply to comment #1)
> [1] : I don't think PackageKit makes a distinction between what action is used
> if the package is signed by a trusted key vs. not. For the former we should
> allow this by default, for the latter we should require the admin password and
> not allow to retain such authorizations. Richard, Robin?

I've opened bug 440060 for this.
Comment 4 Richard Hughes 2008-04-13 09:49:26 EDT
I agree with David, sorry. You can change this by editing the policy file yourself.
Comment 5 Martin Jürgens 2008-04-13 10:22:22 EDT
This is just about having sane defaults and not about "i want to revert
authetifications". 

I deeply believe that having "Remember Authorization" set by default when
installing a RPM from some web site is a security issue - because when the user
does not care and just enters his password, every app could easily install some
self-made RPMs without asking for authorization and for example a postinst
script may execute dangerous things then.

So having considered all I'd say, leave "Remember Authorization" unchecked by
default in that case to prevent things like that.

I also noticed bug 440060 but do not really know how it is connected to the
things stated above. Some clear up would be nice. Thanks
Comment 6 Richard Hughes 2008-04-13 13:08:09 EDT
David, is there even a PolicyKit way of specifying policy to allow the admin to
check the box, but for the box to be by default disabled?
Comment 7 David Zeuthen 2008-04-13 15:21:33 EDT
(In reply to comment #6)
> David, is there even a PolicyKit way of specifying policy to allow the admin to
> check the box, but for the box to be by default disabled?

No.
Comment 8 David Zeuthen 2008-04-13 15:40:54 EDT
(In reply to comment #5)
> This is just about having sane defaults and not about "i want to revert
> authetifications". 
> 
> I deeply believe that having "Remember Authorization" set by default when
> installing a RPM from some web site is a security issue
> - because when the user
> does not care and just enters his password, every app could easily install some
> self-made RPMs without asking for authorization and for example a postinst
> script may execute dangerous things then.

This is wrong as per the latest PolicyKit packages (landed 5-6 days ago in
Rawhide), see [0].

> So having considered all I'd say, leave "Remember Authorization" unchecked by
> default in that case to prevent things like that.

This is just bogus. Either we decide that we won't keep authorizations or we
decide that we'll let users keep authorizations. If you think leaving a checkbox
unchecked is going to help anything then, sorry, you are misguided. I mean,
making security rely on a user not checking a box is not security.

Instead you should just request that keeping an authorization shouldn't be
possible (by default) and if you manage to convince the PackageKit team of this
then it's a single one line change for them. That's it.


> I also noticed bug 440060 but do not really know how it is connected to the
> things stated above. Some clear up would be nice. Thanks

The idea is that installing RPM's provided by a trusted 3rd party (such as the
Fedora Project) is a different thing that installing an RPM from some weblog. 

For the former (signed by trusted key) you want to avoid keep asking the user
for his password and allow to keep the authorization. Heck, we could even grant
this authorization without requiring a password because we've already decided to
trust the provider.

For the latter (not signed by a trusted key) you always want to ask for the
admin password (e.g. root password) and you don't allow to keep that
authorization (e.g. no check boxes).

I believe that when bug 440060 is resolved your concerns about installing random
RPM's off the interwebs should be addressed. But Richard tells me that require
some major surgery of PackageKit. Richard, do you have plans on fixing that bug
for F10? It's really important and it's better to get this right earlier than later.

      David

[0] : See 

http://hal.freedesktop.org/docs/PolicyKit/polkit-polkit-authorization-constraint.html

For example

scope=always:action-id=org.freedesktop.packagekit.update-package:when=1207962380:auth-as=0:constraint=local:constraint=active:constraint=exe%3A%2Fusr%2Fbin%2Fgpk-update-viewer:constraint=selinux_context%3Aunconfined_u%3Aunconfined_r%3Aunconfined_t%3ASystemLow-SystemHigh

This means the authorization obtained can only be used by
/usr/bin/gpg-update-viewer and that it has to run in that security context. [1]

[1] : of course since the windowing system (X.org) and toolkit (gtk) isn't yet
secure this doesn't add much security [2]; e.g. there's still plenty of ways to
run code pretending to be /usr/bin/gpg-update-viewer. It's a bit complicated
though (would require an active attack). But that might change in the future via
things like XACE, other security initiatives and by properly securing the
PackageKit UI tools.

[2] : see
http://hal.freedesktop.org/docs/PolicyKit/polkit-polkit-sysdeps.html#polkit-sysdeps-get-exe-for-pid
for the longer story
Comment 9 Martin Jürgens 2008-04-13 15:50:10 EDT
Thanks for the clear up. I now understand the backgrounds.

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