Bug: https://bugs.freedesktop.org/show_bug.cgi?id=84313Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=24307

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=24307Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=24307Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=24307Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=24307Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Usage:

$ dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus \
      org.freedesktop.DBus.Debug.Stats.GetAllMatchRules
method return sender=org.freedesktop.DBus -> dest=:1.13 reply_serial=2
   array [
      dict entry(
         string ":1.4"
         array [
         ]
      )
      dict entry(
         string ":1.9"
         array [
            string "type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged'"
         ]
      )
      dict entry(
         string ":1.11"
         array [
            string "eavesdrop='true'"
         ]
      )
   ]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=24307Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

I wish I could say "I can't believe this was never documented", but
it wouldn't be true.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=24307
Reviewed-by: Alban Crequy

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83968Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

The message type is more important than whether NO_REPLY_EXPECTED is
set, when deciding whether a reply is expected. This documents
existing practice in at least libdbus, GDBus and dbus-daemon.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75749
Reviewed-by: Thiago Macieira

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73689
Reviewed-by: Ralf Habacker
[add <dbus/dbus-sysdeps-unix.h> which is now required for
_dbus_fd_set_close_on_exec -smcv]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83583Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83622Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
[add dbus-sysdeps-unix.h as required for close-on-exec in master -smcv]

Conflicts:
	NEWS
	configure.ac

Print more details when receiving a file descriptor.

Before:
   unix fd 5

After:
   file descriptor
         inode: 1030
         type: char
   file descriptor
         inode: 295664
         type: socket
         address family: unknown (16)
   file descriptor
         inode: 295665
         type: socket
         address family: inet
         name 127.0.0.1 port 47723
         peer 127.0.0.1 port 22
   file descriptor
         inode: 295666
         type: socket
         address family: unix
         name @/tmp/d67s774Sws0pEra
   file descriptor
         inode: 295667
         type: socket
         address family: unix
         name @
         peer @

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80603Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80603Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

The differences has been found out by comparing with the cross compiled
mingw..-dbus packages.

[exclude system bus support bits on Windows -smcv]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83583Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

There is no system bus on Windows, and there won't be until/unless
it can be secure.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83583Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>

On Unix, the thing that can be made close-on-exec is a file descriptor,
which is an int.

On Windows, the thing that can be made close-on-exec is a HANDLE,
which is pointer-sized (but not necessarily a pointer!). In practice,
on Windows we only called _dbus_fd_set_close_on_exec() on socket
pseudo-file-descriptors (SOCKET, which is an unsigned int);
every SOCKET can validly be cast to HANDLE, but not every HANDLE
is a SOCKET.

Before this commit we used an intptr_t as a sort of fake
union { int; HANDLE; }, which just obscures what's going on.

In practice, everything that called _dbus_fd_set_close_on_exec()
is really platform-specific anyway, so let's just have two separate
functions and call this solved.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39610

This addresses CVE-2014-3635.

If (*n_fds * sizeof (int) % sizeof (size_t)) is nonzero,
then CMSG_SPACE (*n_fds * sizeof (int)) > CMSG_LEN (*n_fds * sizeof (int)
because the SPACE includes padding to a size_t boundary, whereas the LEN
does not. We have to allocate the SPACE. Previously, we told the kernel
that the buffer size we wanted was the SPACE, not the LEN, which meant
it was free to fill the padding with additional fds: on a 64-bit
platform with 32-bit int, that's one extra fd, if *n_fds happens
to be odd.

This meant that a malicious sender could send exactly 1 fd too many,
which would make us fail an assertion if enabled, or overrun a buffer
by 1 fd otherwise.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83622Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>

This means we can use _DBUS_STATIC_ASSERT at non-global scope without
tripping -Wunused-local-typedefs.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83767Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
(cherry picked from commit 0e3d08d4)

This is one of four commits needed to address CVE-2014-3637.

The bus uses _dbus_connection_set_pending_fds_function and
_dbus_connection_get_pending_fds_count to be notified when there are pending
file descriptors. A timeout per connection is armed and disarmed when the file
descriptor list is used and emptied.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This is one of four commits needed to address CVE-2014-3637.

This will allow the bus to be notified whenever a file descriptor is added or
removed from a DBusConnection's DBusMessageLoader.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This is one of four commits needed to address CVE-2014-3637.

This will allow the bus to know whether there are pending file descriptors in a
DBusConnection's DBusMessageLoader.

https://bugs.freedesktop.org/show_bug.cgi?id=80559Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[fix compilation on platforms that do not HAVE_UNIX_FD_PASSING -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This is one of four commits needed to address CVE-2014-3637.

When a file descriptor is passed to dbus-daemon, the associated D-Bus message
might not be fully sent to dbus-daemon yet. Dbus-daemon keeps the file
descriptor in the DBusMessageLoader of the connection, waiting for the rest of
the message. If the client stops sending the remaining bytes, dbus-daemon will
wait forever and keep that file descriptor.

This patch adds pending_fd_timeout (milliseconds) in the configuration to
disconnect a connection after a timeout when a file descriptor was sent but not
the remaining message.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This addresses the parts of CVE-2014-3639 not already addressed by
reducing the default authentication timeout.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80851
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This partially addresses CVE-2014-3639.

This will change the default on the system bus where the limit
  <limit name="auth_timeout">...</limit>
is not specified.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This addresses CVE-2014-3636.

Based on a patch by Alban Crequy. Now that it's the same on all
platforms, there's little point in it being set by configure/cmake.

This change fixes two distinct denials of service:

fd.o#82820, part A
------------------

Before this patch, the system bus had the following default configuration:
- max_connections_per_user: 256
- DBUS_DEFAULT_MESSAGE_UNIX_FDS: usually 1024 (or 256 on QNX, see fd.o#61176)
  as defined by configure.ac
- max_incoming_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
- max_outgoing_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
- max_message_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS = usually 1024

This means that a single user could create 256 connections and transmit
256*4096 = 1048576 file descriptors.

The file descriptors stay attached to the dbus-daemon process while they are
in the message loader, in the outgoing queue or waiting to be dispatched before
D-Bus activation.

dbus-daemon is usually limited to 65536 file descriptors (ulimit -n). If the
limit is reached and dbus-daemon needs to receive a message with a file
descriptor attached, this is signalled by recvfrom with the flag MSG_CTRUNC.
Dbus-daemon cannot recover from that error because the kernel does not have any
API to retrieve a file descriptor which has been discarded with MSG_CTRUNC.
Therefore, it closes the connection of the sender. This is not necessarily the
connection which generated the most file descriptors so it can lead to
denial-of-service attacks.

In order to prevent DoS issues, this patch reduces DEFAULT_MESSAGE_UNIX_FDS to
16:

max_connections_per_user * max_incoming_unix_fds = 256 * 64 = 16384

This is less than the usual "ulimit -n" (65536) with a good margin to
accomodate the other sources of file descriptors (stdin/stdout/stderr,
listening sockets, message loader, etc.).

Distributors on non-Linux may need to configure a smaller limit in
system.conf, if their limit on the number of fds is smaller than
Linux's.

fd.o#82820, part B
------------------

On Linux, it's not possible to send more than 253 fds in a single sendmsg()
call: sendmsg() would return -EINVAL.
  #define SCM_MAX_FD      253

SCM_MAX_FD changed value during Linux history:
- it used to be (OPEN_MAX-1)
- commit c09edd6eb (Jul 2007) changed it to 255
- commit bba14de98 (Nov 2010) changed it to 253

Libdbus always sends all of a message's fds, and the beginning
of the message itself, in a single sendmsg() call. Combining these
two, a malicious sender could split a message across two or more
sendmsg() calls to construct a composite message with 254 or more
fds. When dbus-daemon attempted to relay that message to its
recipient in a single sendmsg() call, it would receive EINVAL,
interpret that as a fatal socket error and disconnect the recipient,
resulting in denial of service.

This is fixed by keeping max_message_unix_fds <= SCM_MAX_FD.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>

This addresses CVE-2014-3638.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=81053Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This requires a little bit of code re-ordering, because
_DBUS_STATIC_ASSERT can appear anywhere that a variable declaration
would be valid, i.e. not after executable code.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83767Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>

This means we can use _DBUS_STATIC_ASSERT at non-global scope without
tripping -Wunused-local-typedefs.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83767Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>

Whenever I forget to turn off corekeeper, the regression tests
take ages to record all test-segfault's crashes.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83772Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>

Conflicts:
	NEWS

systemd 209 merged all the libraries to libsystemd. Old
libraries can still be enabled with --enable-compat-libs
switch in systemd but this increases the binary size.

Implement a fallback library check in case compat libraries
dont exist.

[Fixed underquoting; switched priority so we try libsystemd first -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>