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

[Olivier Galibert]

Not sure of practical it would be, but 3 makes one immediately think
of stdin, stdout and stderr, which could make sense.

  OG.


On Wed, Oct 8, 2014 at 9:46 AM, Mikkel Kamstrup Erlandsen
<mikkel.kamstrup at gmail.com> wrote:
> 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
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>