[packagekit] Treating untrusted and trusted operations differently

[Richard Hughes]

We use PolicyKit to let us to cool stuff as the user -- for instance
prompting the user for the admin password to install files.

But what if you trust these files? Should you even have to authenticate
at all? For instance, I trust _anything_ that comes from fedora-updates,
signed with their trusted key. I want any application to be able to
install updates from that repo with that key without even asking me for
auth AT ALL. If I'm installing a service pack full of updates from a
CDROM with all packages signed by Fedora, then that's pretty safe too.

But, I don't want a session user that is compromised to be able to
install untrusted rpm's from a compromised mirror, or for users to be
able to install untrusted (read unsigned, or signed with an untrusted
key) from USB pendrives.

What I propose (please read entire email!) is converting the methods to:

InstallFile(BOOL trusted, STRING file)
UpdatePackage(BOOL trusted, STRING package_id)

so that if you get a trusted=FALSE and the transaction only contain
valid gpg trusted packages, then it succeeds. If any packages are
untrusted, then a special error code is thrown and the transaction
finishes.

If the transaction fails, then the client tools re-request the method
with trusted=TRUE (which will require authentication) and the method
succeeds. This two-shot auth can be done automatically in libpackagekit
or libpackagekit-gnome and so should be perfectly transparent.

So: the use case to justify this big change. We say:

* InstallPackage trusted allows trusted packages to install without auth
* InstallPackage untrusted requires the admin password

So, if totem is wanting to install codecs it can just get on and do them
without even asking the user for auth; the files are trusted and
therefore we implicitly trust the source.

If totem ever got hacked, and wanted to install files from a compromised
mirror then the zero-auth install would fail, and the admin password
would be required before totem could install the untrusted package.

So, on the hacked mirror. You've probably asked gpk-update-icon to
automatically apply updates and remember that auth for the future. If a
mirror got hacked and a gpg signed package replaced with a non-gpg
signed package, then updated package could be downloaded and
automatically installed. Not cool.

Similarly, if somebody gave you a pendrive full of updates, they could
all be installed without a password if they are pre-trusted, but is they
tried to sneak in an unsigned update, this would require the admin
password before installing.

Now, a more limited change would be to make all methods fail on
non-signed packages, and provide an extra method to install a untrusted
signed rpm, for instance the livna.org repo rpm. This would remove the
drastic API change (phew!). This would fail in a horrible way for
distros such as rawhide (all packages are unsigned) but I think we could
probably change that. David, assuming we get rawhide signed, what would
stop us doing exactly that?

Richard.