It appears this change may cause intermittent slow or failed boot,
more commonly on slower/older machines, in at least Mageia and
possibly also Debian. This would indicate that while the system
is under load, system services are not completing authentication
within 5 seconds.
This change was not the main part of fixing CVE-2014-3639, but does
help to mitigate that attack. As such, increasing this timeout makes
the denial of service attack described by CVE-2014-3639 somewhat
more effective: a local user connecting to the system bus repeatedly
from many parallel processes can cause other users' attempts to
connect to take longer.
If your machine boots reliably with the shorter timeout, and
resilience against local denial of service attacks is important
to you, putting this in /etc/dbus-1/system-local.conf
or a file matching /etc/dbus-1/system.d/*.conf can restore
the lower limit:
Jacek Bukarewicz [Fri, 14 Nov 2014 18:39:38 +0000 (18:39 +0000)]
Set error when message delivery is denied due to receive rule
This makes bus_context_check_security_policy follow convention of
setting errors if function indicates failure and has error parameter.
Notable implication is that AccessDenied error will be sent if sending message
to addressed recipient is denied due to receive rule. Previously, message
was silently dropped.
This also fixes assertion failure when message is denied at addressed recipient
while sending pending auto activation messages.
Simon McVittie [Tue, 4 Nov 2014 14:41:54 +0000 (14:41 +0000)]
CVE-2014-7824: set fd rlimit to 64k for the system dbus-daemon
This ensures that our rlimit is actually high enough to avoid the
denial of service described in CVE-2014-3636 part A.
CVE-2014-7824 has been allocated for this incomplete fix.
Restore the original rlimit for activated services, to avoid
them getting undesired higher limits.
(Thanks to Alban Crequy for various adjustments which have been
included in this commit.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=85105 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Simon McVittie [Mon, 15 Sep 2014 17:37:59 +0000 (18:37 +0100)]
Add NetBSD to the list of platforms where credentials-passing a pid should work
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69702 Reviewed-by: Patrick Welche <prlw1@cam.ac.uk> Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk> Tested-by: Patrick Welche <prlw1@cam.ac.uk>
Simon McVittie [Mon, 15 Sep 2014 17:38:49 +0000 (18:38 +0100)]
test_processid: only assert that it works if we expect it to work
Otherwise, this would fail on, for instance, QNX.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69702 Reviewed-by: Patrick Welche <prlw1@cam.ac.uk> Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk> Tested-by: Patrick Welche <prlw1@cam.ac.uk>
Patrick Welche [Thu, 30 Oct 2014 12:39:26 +0000 (12:39 +0000)]
whitespace/comment fixes
[originally part of the previous commit -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69702 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Patrick Welche [Tue, 29 Jul 2014 13:08:20 +0000 (14:08 +0100)]
Implement NetBSD credentials-passing with LOCAL_PEEREID
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69702 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk> Tested-by: Patrick Welche <prlw1@cam.ac.uk>
Simon McVittie [Mon, 15 Sep 2014 17:04:36 +0000 (18:04 +0100)]
dbus-daemon test: don't assert we pass uid/pid on unknown Unix platforms
We know that Linux, FreeBSD and OpenBSD are "first class citizens"
for credentials-passing, with NetBSD not far behind: people have
turned up on the bug tracking system and told us that tests passed.
On other Unixes, we can't really assert that it works, until someone
who runs them tells us that it worked for them.
Additions to these lists are welcome.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69702 Reviewed-by: Patrick Welche <prlw1@cam.ac.uk> Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk> Tested-by: Patrick Welche <prlw1@cam.ac.uk>
Simon McVittie [Thu, 11 Sep 2014 09:59:32 +0000 (10:59 +0100)]
dbus-spawn: do not forget the exec() errno when the grandchild exits
As is already noted in a comment in
_dbus_babysitter_set_child_exit_error(), if the grandchild fails
to exec() the desired process, we get both CHILD_EXEC_FAILED (with
an errno) and CHILD_EXITED (with a status), and we want to report
the former, since it is more informative. However, clearing
sitter->errnum meant we lose the errno value.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=24821 Reviewed-by: Ross Lagerwall
Simon McVittie [Wed, 8 May 2013 15:58:08 +0000 (16:58 +0100)]
Stop asserting that we're not using the dummy lock implementation
That implementation no longer exists, so neither 0xABCDEF nor 0xABCDEF2
has any special meaning any more.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Simon McVittie [Wed, 29 Oct 2014 14:10:48 +0000 (14:10 +0000)]
Use a better NoReply message for disconnection with reply pending
As an implementation detail, dbus-daemon handles this situation by
artificially triggering a timeout (even if its configured timeout for
method calls is in fact infinite). However, using the same debug message
for both is misleading, and can lead people who are debugging a service
crash to blame dbus-daemon instead, wasting their time.
Simon McVittie [Mon, 8 Sep 2014 19:18:22 +0000 (20:18 +0100)]
Consistently save and restore errno
Some functions in dbus-transport-socket.c make a (wrapped)
socket syscall, then call other APIs, then test the result and
errno of the socket syscall.
This would break horribly if those "other APIs" overwrote errno with
their own value (... and this is part of why errno is an awful API).
Notably, if running under DBUS_VERBOSE, _dbus_verbose() is basically
fprintf(), which sets errno; and our Unix fd-passing support
makes calls of the form _dbus_verbose ("Read/wrote %i unix fds\n", n)
between the syscall and the result processing.
Maybe one day we'll convert all of dbus' syscall wrappers to either
raise a DBusError, or use the "negative errno" convention that systemd
borrowed from the Linux kernel, and in particular, we would need to
do that if we ever ported it to a platform where socket error reporting
was not basically errno. However, in practice everyone uses something
derived from BSD sockets, so "this sets errno, you know what errno is"
is a good enough internal API if we make sure to use it correctly.
Nothing calls _dbus_get_is_errno_nonzero(), so I just removed it instead
of converting it to the new calling convention.
Simon McVittie [Thu, 25 Sep 2014 12:19:24 +0000 (13:19 +0100)]
dbus-spec, dbus-protocol: add ALLOW_INTERACTIVE_AUTHORIZATION flag
Heavily based on a patch from Lennart Poettering.
This is useful for authentication frameworks such as polkit, but this
flag is supposed to be generic, and not be bound to any implementation
of such a framework.
The dbus specification already clarifies that unknown flags must be
ignored, the reference implementation and the other implementations we
checked indeed ignore any new flags, hence we should be fine with
compatibility here.
Simon McVittie [Fri, 24 Oct 2014 12:41:13 +0000 (13:41 +0100)]
test-bus, test-dbus: close any inherited fds from caller
It is probably a bug for them to pass us any fds without close-on-exec;
but apparently CMake has this bug, and so does at least some NetBSD GUI
environment. Cope.
Simon McVittie [Fri, 24 Oct 2014 12:42:57 +0000 (13:42 +0100)]
cmake: only copy session.conf and system.conf into test data dir
Historically, CMake used the glob *.conf.in whereas Autotools listed
the files explicitly. This used to be equivalent, but broke down
when we added example-*.conf.in which are just snippets rather than
complete configuration files (they're intended to go in session.d
or system.d, or otherwise get included by the main config file).
Simon McVittie [Wed, 10 Sep 2014 15:20:52 +0000 (16:20 +0100)]
dbus_shutdown: document its effect on shared connections
In practice, the sort of applications that call dbus_shutdown()
(e.g. regression tests) will want to either use private connections,
or turn off exit-on-disconnect on the shared connection, or both.
Let pkg-config expand directory variables recursively
In particular this makes them more MinGW-friendly: pkg-config on Windows
has specific code to rewrite the ${prefix} when installed in a
different prefix.
[add @datarootdir@, expand commit message -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75858
Simon McVittie [Tue, 23 Sep 2014 16:43:30 +0000 (17:43 +0100)]
Expand documentation of NO_REPLY_EXPECTED
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.
Simon McVittie [Tue, 23 Sep 2014 18:25:31 +0000 (19:25 +0100)]
inotify: make sure we set the close-on-exec flag
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]
Simon McVittie [Wed, 17 Sep 2014 16:19:53 +0000 (17:19 +0100)]
New test for fd-passing
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83622 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
[add dbus-sysdeps-unix.h as required for close-on-exec in master -smcv]
Simon McVittie [Thu, 11 Sep 2014 11:04:04 +0000 (12:04 +0100)]
Split _dbus_fd_set_close_on_exec into Unix and Windows versions
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.
Simon McVittie [Tue, 9 Sep 2014 11:44:22 +0000 (12:44 +0100)]
_dbus_read_socket_with_unix_fds: do not accept extra fds in cmsg padding
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=83622 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Alban Crequy [Mon, 21 Jul 2014 16:17:11 +0000 (17:17 +0100)]
bus: enforce pending_fd_timeout
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=80559 Reviewed-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=80559 Reviewed-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>
Alban Crequy [Mon, 21 Jul 2014 16:34:08 +0000 (17:34 +0100)]
config: add new limit: pending_fd_timeout
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=80559 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Fri, 12 Sep 2014 14:51:39 +0000 (15:51 +0100)]
config: change DEFAULT_MESSAGE_UNIX_FDS to 16
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:
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=82820 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Simon McVittie [Thu, 11 Sep 2014 11:55:52 +0000 (12:55 +0100)]
Replace some runtime assertions with compile-time assertions
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=83767 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
projects / thirdparty / dbus.git / log
