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

[Lennart Poettering]

On Tue, 07.10.14 13:56, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> * kdbus does not allow fds to be attached to a broadcast message, and
>   the kdbus developers have suggested that dbus-daemon should apply the
>   same restriction so malicious processes can't use it for
>   amplification. Does anything actually send fds in broadcasts, either
>   on the system bus or session bus? I haven't found any examples.

Yeah, this is something I would block.

> * It is harder for an abusive process to be a problem if it is only
>   allowed to send a few fds per message, which is why 1.8.8 dropped
>   the default per-message limit from 1024 to 16. Can this limit drop
>   further? Does anything send more than one fd per message on the
>   system bus? I haven't found any examples on the system bus, but
>   there *are* applications that send more than one at a time on the
>   session bus.

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

The rationale for this is that in some context it might be advisable
to allow daemons to pass open connection fds back to the init system
across daemon restarts. (usecase: journald currently loses connection
to all daemon's stdout/stderr if it is restarted, since there's no
good place to place those fds to).

Now, the current socket activation logic allows passing arbitrary
numbers of sockets, and this is heavily used, for example to pass
sockets for AF_UNIX, IPv4, IPv6 and maybe even some bound to multiple
interfaces over. THis is something we certainly want to keep when
adding a new bus-based interface for this.

In fact I figure 16 already is quite low for this usecase...

(Also note that such a socket activation logic would actually be much
closer to the way MacOS does it, since they also pass the fds via IPC
rather via exec() to the daemons. They mostly do this to allow
dynamically adding new sockets to listen on without always requiring
the daemon to restart). 

> * The denial of service risk is primarily on the system bus.
>   Would it be feasible to lock down the system bus configuration
>   so only specific uids are allowed to send/receive fds, or so only
>   specific well-known names are allowed to send/receive fds, or
>   something similar, requiring system services that use fds to
>   declare that they do so? All the examples I've found are a
>   trusted system process at either the sending or receiving end.

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.

Lennart

-- 
Lennart Poettering, Red Hat