Security considerations in PolicyKit-enabled daemons

[David Zeuthen]

On Tue, 2009-07-14 at 14:40 +0100, Richard Hughes wrote:
> I've spent a few minutes writing up some documentation about security
> and PackageKit. These notes probably apply to most of the PolicyKit
> enabled daemons, and they might be useful to somebody. I'm also not
> sure whether my concern over a custom "always authenticate" session
> helper is valid, as I admit i don't fully understand the setuid aspect
> of the session helpers. I would appreciate review from any of you on
> this list.
> 
> Please bear in mind it's work in progress:
> http://cgit.freedesktop.org/packagekit/plain/docs/security.txt

This sounds like a good idea; some comments

 - nitpick: It's D-Bus, not D-BUS or DBus

 - nitpick: it's polkitd-1, not polkit-daemon-1. But generally you
   should refer to either org.freedesktop.DBus.PolicyKit1 or (better)
   "PolicyKit Authority" when talking about polkit interactions. E.g.
   the name of the binary or the D-Bus service name are mostly just
   implementation details...

- It might be good to put this kind of information in a man page; I've
   done something similar for polkit itself here

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

   which is still work-in-progress. There probably should be some more
   discussion about how to choose the defaults for implicit
   authorizations e.g. when to choose "auth_admin" and when to choose
   "auth_self_keep" etc.

 - How about replacing 

     "the daemon asks polkit-daemon-1 for authentication, which then
      blocks until the authentication is completed. This is handled
      asynchronously, and the daemon can process other requests whilst
      waiting for user input."

   with

     "The daemon checks with the PolicyKit Authority for whether the
      client is authorized for the action the client wants to perform.
      This may involve having the user authenticate that he is either
      the user (by authenticating with his password) or that he is
      an administrative user (by authenticating with the root
      password or the password of a user designated as an
      administrative user). The authorization check can take a while
      and the daemon can process other requests whilst waiting for
      user input."

   It's much longer and a bit terse but it's also a lot more accurate.

   Would probably be good to include a link to the PolicyKit-1 man page
   that explains (is supposed to, anyway) the system architecture being
   used (see below).

 - It might be worth going over each registered PolicyKit action and
   explaining why the default implicit authorizations (e.g.
   auth_admin_keep) are secure choices. I think this is really
   important.

 - I'm having a hard time parsing this

    * A session service can be written to automatically authenticate
      methods, and replace the native client. This is hard to mitigate,
      as as soon as you have untrusted code running in the session, it's
      very easy to load exploit code using GTK_MODULES into previously
      trusted applications, such as gpk-application.

   but I don't think it's accurate. Even if you have hostile/malicious 
   client code it can't get past PolicyKit if you use auth_admin...
   Unless it knows the root password, that is... (but then you've
   already lost).

Hope this helps.

     David