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
_______________________________________________
polkit-devel mailing list
polkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/polkit-devel
