Agent Authentication Question

Colin Walters walters at verbum.org
Wed Jun 3 14:22:03 PDT 2015



On Wed, Jun 3, 2015, at 03:40 PM, Miloslav Trmač wrote:
> 
> Isn’t this a privilege escalation actually?
> 
> Mallory creates creates auth_admin* sessions for all possible cookie values, and waits for Alice to (or social-engineers Alice to) create a new auth_admin session for an unrelated purpose and to authenticate as the admin. Then, depending on the hash order in get_authentication_session_for_cooke, Alice’s authentication may in fact apply to one of Mallory’s sessions. Sure, one effect would be that Alice’s polkit authentication session is not authenticated and her authorization request fails, but the more important effect is that Mallory’s authorization request succeds as properly authenticated by $admin.

Yes, I think you're right.

So...I submitted https://bugs.freedesktop.org/show_bug.cgi?id=90832 while working on this, but I accidentally pushed it =/  Want to post-commit review?  Or should I just revert it?

I'm still thinking about stronger approaches.  I think the strongest thing we could do would be to enforce the binding of cookie -> agent.  Given that there can be at most one agent per uid, and we always expect that the reply comes from that same uid, we could bind cookie <-> uid <-> agent.  However, because of the setuid binary, we don't know the invoking uid.  

# Idea 1: Pass and verify uid 
 - Add a new API AuthenticationAgentResponse2 which also takes a uint32 uid.
 - Change polkit-agent-helper-1 to read the real uid, and try calling the new API, falling back if it doesn't exist (for the case where a package is upgraded but the service wasn't restarted)
 - Change get_authentication_session_for_cookie() to match session->subject with that uid

# Idea 2: Make cookies secure
 - Raw cookie is g_strdup_printf ("cookie-%s-%u", random_cookie, uid)
 - Daemon has a secret key generated on startup
 - Compute an HMAC[1] over the raw cookie, using the secret key
 - Verify HMAC in AuthenticationAgentResponse

  I did something like this for the original Cockpit auth where the cookie is literally a
  web browser cookie which is a cache of Cockpit verifying username+password,
  along with a timestamp so it can be expired.

[1] http://en.wikipedia.org/wiki/Hash-based_message_authentication_code




More information about the polkit-devel mailing list