Agent Authentication Question

Colin Walters walters at verbum.org
Thu Jun 4 06:20:42 PDT 2015



On Thu, Jun 4, 2015, at 07:49 AM, Miloslav Trmač wrote:
> Hello,
> > 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
> 
> No, it is per session or per PID. (polkit_backend_interactive_authority_register_authentication_agent)

Right.  Though, [below]

> 
> > and we always expect that the reply
> > comes from that same uid
> 
> This is not obvious to me; could there be a kiosk, or application separation (UID-per-application) system where the desktop session runs an agent with a different UID than the confined application which is requesting an operation?

The setuid helper is invoked by the agent, not the application.  I can't think
of a scenario in which they'd be different.  (I had some other text here around
multi-uids preserved below[1] which are less important than this fundamental point).

In that case, while a user could have multiple sessions and agents, we can
still enforce that the uid that spawned the agent is the same as the one
calling the setuid helper.

> 
> > # 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
> 
> The issue we have is not cookies are not legitimate, it is that there are collisions; we can already detect made-up cookies simply by not finding any matching session. E.g. HMAC(the-old-32-bit-counter) would not help at all.

Note that I was suggesting that the cookie include the uid.  Thus the HMAC authenticates
the uid, and we can detect when passed a cookie from a "foreign" agent.

> As far as the DoS, either the cookies need to be unpredictable _and_ not revealed (/usr/lib/polkit-1/polkit-agent-helper-1’s command line currently publishes the cookie), or bound to the agent somehow; but because the agent and the agent helper are distinct, it seems to me that making the cookies unpredictable and passing them through a private channel would be both reliable and simple.

I think you're right.  I'll look at making this change.  The HMAC
approach is slight overkill.

But I'd be most comforatable if we did *both* "uid binding" and "secret cookie".

[1] 

I don't think Android-like use of uids is compatible with polkit as it exists today.  I'm
not aware of anyone shipping a real-world system that tries that, for several reasons.
First is that separate uids don't help you if they all have raw access to the X server,
because X allows any client to do anything.  Sandboxing is being investigated
with Wayland, but there's still a number of open items there.


More information about the polkit-devel mailing list