Security considerations in PolicyKit-enabled daemons
david at fubar.dk
Tue Jul 14 08:47:41 PDT 2009
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:
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
- It might be good to put this kind of information in a man page; I've
done something similar for polkit itself here
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
- 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."
"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
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
- 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
Hope this helps.
More information about the polkit-devel