The patch issued by the D-Bus maintainers for CVE-2014-3636 was based on
incorrect reasoning, and does not fully prevent the attack described as
"CVE-2014-3636 part A", which is repeated below. Preventing that attack
requires raising the system dbus-daemon's RLIMIT_NOFILE (ulimit -n) to a
higher value.

To avoid propagating that higher limit to activatable system services,
it is desirable to start the system dbus-daemon as root so it can store
its previous limit, raise its limit, drop root privileges (which its
default configuration will do automatically), and restore the previous
limit before launching activatable services. Some operating system
distributions, such as anything using the upstream-supplied systemd
units, start the system dbus-daemon as root already; others, such as
Debian 7, currently start the system dbus-daemon under its less
privileged uid and will need minor modifications to their init scripts.

Suggested patches are attached. Patch 0001 is not strictly required, but
if it is skipped, it will be necessary to replace each occurrence of
DBUS_SYSTEM_LOG_WARNING with DBUS_SYSTEM_LOG_INFO in patch 0002.

Attack details (repeating CVE-2014-3636 part A):

By queuing up the maximum allowed number of fds, a malicious sender
could reach the system dbus-daemon's RLIMIT_NOFILE (ulimit -n, typically
1024 on Linux). This would act as a denial of service in two ways:

* new clients would be unable to connect to the dbus-daemon
* when receiving a subsequent message from a non-malicious client that
  contained a fd, dbus-daemon would receive the MSG_CTRUNC flag,
  indicating that the list of fds was truncated; kernel fd-passing APIs
  do not provide any way to recover from that, so dbus-daemon responds
  to MSG_CTRUNC by disconnecting the sender, causing denial of service
  to that sender