Security considerations in PolicyKit-enabled daemons

[Richard Hughes]

2009/7/14 David Zeuthen <david at fubar.dk>:
>  - nitpick: It's D-Bus, not D-BUS or DBus

Fixed.

>  - 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...

Right, but I wanted to document it a bit more concrete than an
abstract authority, it's a process people can look at. Anyway, I've
changed this to polkitd-1, thanks.

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

I guess, but I don't want to scare the bejesus out of people without
them looking for it.

>  - How about replacing
>   It's much longer and a bit terse but it's also a lot more accurate.

I've used your description, with a few grammatical changes, thanks.

>   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).

Is there a web-link for this?

>  - 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.

Yes; do you think this should be done as comments in the policy file,
or in the security document? It seems they could get out of sync if
the rationale isn't in the policy document.

>  - 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).

My concern was that a user could take the polkit-gnome sources, and
hack out the mechanism part and run it instead of the gnome helper,
thus not showing the authentication box. Matthias wasn't sure if there
was some sort of setuid thing going on here, and I'm not sure of the
exact logic either. If you could explain this it would be great.
Thanks.

Richard.