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

[Simon McVittie]

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:

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

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.

Sorry if this makes your APIs less nice, but I don't think we can safely
put the fd limit back up, and I don't think you can avoid supporting
multiple messages anyway, at which point you might as well do one fd per
message.

> In my usecase above it would be possibly untrusted system services
> pushing fds into the priviliged init system, as well as getting them
> back from it.

OK, so that doesn't change anything I said in my email: we can't rely on
both ends of a fd-passing transaction being trusted, but we might be
able to rely on at least one end being trusted.

    S