Agent Authentication Question

[Miloslav Trmač]

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)

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

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


As far as the privilege escalation goes, AFAIK our only concern is that the cookies need to be unique. So, large enough random values, or (something per authority instance, counter) as your patch in #90832 does.  I would be most comfortable with a design that works perfectly reliably even without a random value (though we can add one as a protection against design mistakes), e.g. (PID, authority instance start _in nanoseconds_, per-authority-instance random value, counter).

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. If we don’t use a cookie-like secret to authenticate the relationship between the agent and the helper, we could also try using something structural (checking that the parent of the helper is the registered agent, looking up their sessions and the like) but that is fairly likely to be racy, and especially when the agent is registered for an individual subject PID, not a session, we don’t have much to go on.
    Mirek