max connections per control group (cgroup)

[Lennart Poettering]

On Thu, 14.08.14 14:55, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

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

Indeed, this is still racy, even in the dbus case, to a level that makes
me feel a bit uncomfortable about using this for policy.

I understand that Alaban's patch is primarily supposed to be a
protection against run-away clients rather than a real security
functionality, but I think we should be more careful here.

If figure the right way is to get this done:

https://lkml.org/lkml/2013/8/27/318

This will solve the race only for datagrams, but then a similar scheme
could be added for streams, similar to the relationship of SCM_CREDS and
SO_PEERCRED... I really wished somebody would look into that again. I
think there wasn't too much stuff missing there.

(BTW, sd-login.h currently exposes sd_peer_get_unit(int fd, char **unit)
already, which is vulnerable to this race, and hence useful only for
informational purposes. Would love to port this over to become reliable...)

Lennart

-- 
Lennart Poettering, Red Hat