Security considerations in PolicyKit-enabled daemons

David Zeuthen david at fubar.dk
Tue Jul 14 09:23:53 PDT 2009


On Tue, 2009-07-14 at 17:03 +0100, Richard Hughes wrote:
> >   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?

Not right now. Suggest to just refer to "the PolicyKit-1 man page",
there's ASCII versions in the actual man page so it is just as usable.

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

Maybe in the policy file is fine enough. Then you can just link to that
one.

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

Nope, such an attack is not possible.

The way it works is that when authenticating, polkitd-1 passes a cookie
to the authentication agent. Then if the user enters the right password,
the authentication agent calls AuthenticationAgentResponse()

http://hal.freedesktop.org/docs/polkit/eggdbus-interface-org.freedesktop.PolicyKit1.Authority.html#eggdbus-method-org.freedesktop.PolicyKit1.Authority.AuthenticationAgentResponse

on the Authority with the cookie for the authentication request. If the
caller of AuthenticationAgentResponse() is not uid 0, then it is
ignored. 

The way this works, is that the authentication setuid root
helper, /usr/libexec/polkit-agent-helper-1, does the call. This program
needs to be uid 0 for authentication _anyway_. And it _only_ decides to
invoke this method if you actually successfully authenticated.

This of course relies on /usr/libexec/polkit-agent-helper-1 being a
secure program [1]. But that's fairly easy to verify since this is 326
lines of code and only depends on PAM (which is supposed to be secure as
well) up until we have decided that the user successfully authenticated.

Only when that is done, we initialize other libraries (libglib,
libgobject, libeggdbus, libpolkit-gobject) to send the message. Actually
these dependent libraries are secure as well (providing your sanitize
the environment) but we _don't_ need them until after we have make the
decision (this is just defensive programming, it's strictly not
necessary, we could initialize them before).

Anyway, all this crap is nicely hidden in the PolkitAgentSession class
but it is important to know how it works.

FWIW, in the future, when we have flying cars and a Secure Desktop
(separate X server etc.) for each login session, then we can change
polkitd-1 to only allow authentication agents that are part of the
session of the Secure Desktop. That way _no-one_ can impersonate the
authentication dialogs (if you use the SAK (Secure Attention Key e.g.
ctrl+alt+del) to get it it) and, more importantly, they can't snoop your
keystrokes when entering the password.

Hope this clarifies.

     David

[1] : I'm using the term "secure program" as defined here:

http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/index.html




More information about the polkit-devel mailing list