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 :)
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?
*** Bug 439951 has been marked as a duplicate of this bug. ***
(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.
I agree with David, sorry. You can change this by editing the policy file yourself.
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
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?
(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.
(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
Thanks for the clear up. I now understand the backgrounds.