<div dir="ltr">On 7 October 2014 14:56, Simon McVittie <span dir="ltr"><<a href="mailto:simon.mcvittie@collabora.co.uk" target="_blank">simon.mcvittie@collabora.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">D-Bus has recently had several vulnerabilities involving file descriptor<br>
passing (typical APIs for this feature include DBUS_TYPE_UNIX_FD,<br>
G_VARIANT_TYPE_HANDLE or QDBusUnixFileDescriptor).<br>
<br>
File descriptors imply allocation of kernel memory, so the kernel has to<br>
be careful how many fds it allows. This is fine when fds are passed<br>
directly between processes, but in D-Bus they are passed through an<br>
intermediary (dbus-daemon) and the kernel can't know that dbus-daemon is<br>
not the one to "blame" for those fds, meaning that dbus-daemon has to go<br>
to some lengths to limit abuse by its clients.<br>
<br>
To try to avoid or mitigate any other vulnerabilities that might exist<br>
in this area, I think we should consider locking down fd-passing<br>
further. Here are some specific restrictions we could consider applying<br>
- I would like to know about any examples of real-world applications<br>
that would be broken by these.<br>
<br>
* kdbus does not allow fds to be attached to a broadcast message, and<br>
  the kdbus developers have suggested that dbus-daemon should apply the<br>
  same restriction so malicious processes can't use it for<br>
  amplification. Does anything actually send fds in broadcasts, either<br>
  on the system bus or session bus? I haven't found any examples.<br>
<br>
* It is harder for an abusive process to be a problem if it is only<br>
  allowed to send a few fds per message, which is why 1.8.8 dropped<br>
  the default per-message limit from 1024 to 16. Can this limit drop<br>
  further? Does anything send more than one fd per message on the<br>
  system bus? I haven't found any examples on the system bus, but<br>
  there *are* applications that send more than one at a time on the<br>
  session bus.<br></blockquote><div><br></div><div>From your survey it looks like 2 fds could be an interesting target.<br><br></div><div>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.<br><br></div><div>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).<br><br></div><div>Cheers,<br></div><div>Mikkel<br></div></div></div></div>