[packagekit] Treating untrusted and trusted operations differently

[David Zeuthen]

Hi,

Sorry, this mail is a bit confusing to me. You mention both files and
packages and I think that is what confuses me. I also think you mix up
authentication and authorization. Anyway, some comments inline.

On Mon, 2008-04-21 at 23:35 +0100, Richard Hughes wrote:
> 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.

Except that certain users on the system shouldn't be allowed to do
this. For example

 - I don't want people using the guest account on my laptop to
   install all of GNOME if I'm a KDE use

 - I'd definitely want the account using a KIOSK system to not be
   allowed to do this. 

 - If I had kids, I want to make sure they don't install random
   software off Fedora.

So there needs to be some way of locking this down. And, surprise, this
is why we need to use PolicyKit even for trusted software. 

I do agree that the default user on a laptop shouldn't have to type in
his password to install trusted software. So by default we'd use
allow_active="yes" for the polkit action required to install trusted
software. Then we can always lock it down on a per user basis using
polkit-auth(1) for example.

> 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 this is confusing. Why would the caller need to pass trusted=TRUE or
trusted=FALSE in. Clearly, the PackageKit daemon can check if all
packages are properly signed by a trusted key before really starting the
transaction. Implementation-wise you would do after all the RPM's have
been downloaded but before the transaction runs. [1]

So now the PackageKit daemon knows whether to check that the caller has

 org.freedesktop.packagekit.install-trusted

if all packages are trusted or

 org.freedesktop.packagekit.install-untrusted

if just a single package is trusted. If the caller lacks the proper
authorization you just abort and throw an exception and the UI tools
will prompt the user for authentication to gain that authorization (if
applicable).

(Btw, I'd also use the same PolicyKit action for installing local RPM's
versus installing from a repository or installing from a Service Pack
[sic] disc or whatever. The point really isn't where the user gets an
RPM from (it's utterly uninteresting actually), the point is whether
it's trusted (e.g. signed by a trusted key))

Regarding your totem example: Please read what I wrote in the other
thread where I said the whole libgnome-packagekit business is a bad idea
and why it's better to replace it with a D-Bus service (DE independence,
easier to maintain, user consent, runs sandboxed, etc.). You still owe
me a couple of replies on that thread and I'd prefer to discuss it in
that thread if that's OK with you. I also think it would be useful to
have that discussion in another thread as it's semi-orthogonal to this
problem.

Hope this helps,
David

[1] : Every time I mention that this is the only secure way to do it
someone mentions "but yum and rpm is hard!" and then nothing happens