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

[Mikkel Kamstrup Erlandsen]

On 7 October 2014 14:56, Simon McVittie <simon.mcvittie at collabora.co.uk>
wrote:

> D-Bus has recently had several vulnerabilities involving file descriptor
> passing (typical APIs for this feature include DBUS_TYPE_UNIX_FD,
> G_VARIANT_TYPE_HANDLE or QDBusUnixFileDescriptor).
>
> File descriptors imply allocation of kernel memory, so the kernel has to
> be careful how many fds it allows. This is fine when fds are passed
> directly between processes, but in D-Bus they are passed through an
> intermediary (dbus-daemon) and the kernel can't know that dbus-daemon is
> not the one to "blame" for those fds, meaning that dbus-daemon has to go
> to some lengths to limit abuse by its clients.
>
> To try to avoid or mitigate any other vulnerabilities that might exist
> in this area, I think we should consider locking down fd-passing
> further. Here are some specific restrictions we could consider applying
> - I would like to know about any examples of real-world applications
> that would be broken by these.
>
> * 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.
>
> * 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.
>

>From your survey it looks like 2 fds could be an interesting target.

Also because most IO operations have 2 modes; I and O :-) I could imagine
some service that required two fds, one for I and one for O, be passed in
one message in a transactional way to avoid some race conditions (or
complex book keeping). There are also no Unix APIs I know of that return
more than 2 fds.

When one goes from 3 an up I can't find any good arguments that would make
differences between 3, 6, 11, or 16, to take some random numbers (apart
from the resource argument you bring up).

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20141008/a275e95a/attachment.html>