file descriptor passing in D-Bus: how much is actually used?

[Lennart Poettering]

On Wed, 08.10.14 11:48, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> On 08/10/14 11:07, Lennart Poettering wrote:
> > So, in the systemd context we have been thinking for a while now to
> > add a bus-based alternative to the socket activation fd passing
> > protocol we so far used (which simply passes fds across exec() for
> > newly spawned daemons).
> 
> That makes sense, but...
> 
> > In fact I figure 16 already is quite low for this usecase...
> 
> ... 1024 (older dbus), 16 (dbus >= 1.8.8) and 256 (kdbus) are all a lot
> less than 64k (Linux default fd rlimit), so to make this mechanism fully
> general, I think you're going to have to support splitting the fds
> between multiple messages anyway, something like:

1024 was a ridiculous limit, given that RLIMIT_NOFILES defaults to
1024, so unless people played with that limit in many cases you could
DoS a dbus peer with a single message by exhausting all its fds...

I wasn't really suggesting a substantial increase of the limit. Just
maybe 192 or so.

> * HereIsMyFd(0, handle 0), attached fds = [fd 0]
> * HereIsMyFd(1, handle 0), attached fds = [fd 1]
> ...
> * ReExecMe()
> 
> The 1.8.8 security release had to reduce the fd per message limit to 253
> or less to address CVE-2014-3636 part B: that's a hard limit on the
> number of fds that current Linux will allow in a single sendmsg() on
> Unix sockets. So in principle kdbus could go higher than 256, but
> without new kernel APIs (which seem unlikely, because if we rely on a
> new kernel API it might as well be kdbus) there's no way dbus-daemon on
> Linux can go higher than 253. I think systemd's kdbus <-> Unix socket
> proxy would run into the same issue, unless you run one proxy per
> client.

Yes, the proxy runs as one instance per client.

> Also, to address CVE-2014-3636 part A, there's no way we can allow more
> than 64 fds per message without either increasing our rlimit to some
> huge value (requires privileges that dbus-daemon doesn't always have),
> or reducing the number of connections allowed per uid. 16 is safer.

I am pretty sure that RLIMIT_NOFILES of 1024 is unrealistically small
for most non-trivial daemons these days. systemd bumps it ups to 64k
for itself (though passes on 1024 as before for all services).

I'd probably change dbus to bump its rlimit to 64k, too, on startup,
before dropping privs, if it has the privs to do so in the first
place.

Lennart

-- 
Lennart Poettering, Red Hat