max connections per control group (cgroup)

[Simon McVittie]

On 14/08/14 14:09, Lennart Poettering wrote:
> The race is basically: somebody connects to the bus and quickly drops
> off again, and now you know the PID but cannot make sense of it, because
> the client is already gone.
> 
> But thinking about this, this is probably not actually a problem for the
> dbus case, since the authentication is synchronous, and dbus hence
> always gets a chance to read the path and the race hence goes
> away. Sorry for the confusion.

This sounds uncomfortably close to the race that existed in the unmerged
patchset for Maemo's "libcreds" security framework:

* handshake and authenticate with dbus-daemon
* send a message that a privileged user would be allowed to send but
  you are not
* quickly exec a privileged binary (I think the proof-of-concept
  used ping, which is setuid root)
* if you won the race, dbus-daemon looks in your /proc and sees "oh,
  you're privileged, excellent" and forwards the message

Unpatched dbus is not vulnerable to this, because we receive the
credentials via credentials-passing, once, on the first byte of the
connection, and store them. All further interaction is done with the
credentials that you had when you connected (and if you hand over your
socket to a less-privileged process, it's your own fault you gave it
your house keys and hoped it wouldn't steal anything).

I *think* security frameworks that rummage in /proc during the handshake
are not vulnerable either, because if you exec the setuid binary before
the handshake has completed, you will miss your opportunity to send the
malicious message... but if you can queue up the rest of the client side
of the handshake, plus the malicious message, in the outgoing socket
buffer, and then exec the setuid binary, you might be able to get away
with it, unless the end of the handshake happens to be something that
depends on information that is only sent by dbus-daemon after it has
already done its rummaging and is not feasible to guess?

Bottom line, looking for credentials in /proc is handy for debugging,
but no substitute for actual kernel APIs; and I am uncomfortable with
this style of API, and would not want to merge it without (a) comments
documenting why it is safe and what assumptions it makes, and (b) having
studied it in more detail than I can do right now.

    S