DBUS_COOKIE_SHA1 is dependent on unguessable strings, i.e.
indirectly dependent on high-quality pseudo-random numbers
whereas EXTERNAL authentication (credentials-passing)
is mediated by the kernel and cannot be faked.
On Windows, EXTERNAL authentication is not available,
so we continue to use the hard-coded default (all
authentication mechanisms are tried).
Users of tcp: or nonce-tcp: on Unix will have to comment
this out, but they would have had to use a special
configuration anyway (to set the listening address),
and the tcp: and nonce-tcp: transports are inherently
insecure unless special steps are taken to have them
restricted to a VPN or SSH tunnelling.
Users of obscure Unix platforms (those that trigger
the warning "Socket credentials not supported on this Unix OS"
when compiling dbus-sysdeps-unix.c) might also have to
comment this out, or preferably provide a tested patch
to enable credentials-passing on that OS.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Since Automake 1.13 (released December 2012) the correct way for a
maintainer to specify environment variables has been
AM_TESTS_ENVIRONMENT, with TESTS_ENVIRONMENT reserved for the user.
That doesn't work in older Automake, so drop support for such old
versions.
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89846
If OS builders (distributions) have chosen to use the per-user bus,
this provides two possible modes of operation for compatibility with
existing X session startup hooks.
A legacy-free system can just upload DISPLAY, XAUTHORITY and possibly
DBUS_SESSION_BUS_ADDRESS into dbus-daemon's and systemd's activation
environments, similar to
http://cgit.freedesktop.org/systemd/systemd/tree/xorg/50-systemd-user.sh
installed by systemd (but unlike systemctl,
dbus-update-activation-environment works for traditional
D-Bus-activated services, not just for systemd services).
A system where compatibility is required for environment variables
exported by snippets in /etc/X11/xinit/xinitrc.d (in Red Hat derivatives,
Gentoo, etc.) or /etc/X11/Xsession.d (Debian derivatives) can upload
the entire environment of the X session, minus some selected environment
variables which are specific to a login session (notably XDG_SESSION_ID).
In Debian, I plan to put the former in a new dbus-user-session package
that enables a user-session-centric mode of operation for D-Bus,
and the latter in the existing dbus-x11 package, with the intention that
dbus-x11 eventually becomes a tool for change-averse setups or goes
away entirely.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
The socket path used here, $XDG_RUNTIME_DIR/bus, does not match
what was used in user-session-units, but is what Lennart recommended
on fd.o #61303, and is also what kdbus will use for its bus proxy.
Installation of these units switches D-Bus to a different model of
the system: instead of considering each login session (approximately,
each password typed in) to be its own session, the user-session model
is that all concurrent logins by the same user form one large session.
This allows the same bus to be shared by a graphical session, cron jobs,
tty/ssh sessions, screen/tmux sessions and so on.
Because this is a different world-view, it is compile-time optional:
OS builders can choose which world their OS will live in. The default
is still the login-session model used in earlier D-Bus releases,
but might change to the user-session model in future. Explicit
configuration is recommended.
In OSs that support both models (either for sysadmin flexibility or as
a transitional measure), the OS builder should enable the user bus
units, but split them off into a dpkg binary package, RPM subpackage etc.;
the sysadmin can choose whether to enable the user-session model by
choosing whether to install that package.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
The shared can be used by dbus-daemon and dbus-daemon-launch-helper by exporting
the private symbols needed, reducing the size of dbus by about 500k.
The private symbols are exposed under the version
LIBDBUS_PRIVATE_@VERSION_NUMBER@.
[Altered by Simon McVittie and Ralf Habacker to clear up some
problematic linking.]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This changes the Linux behaviour to match the default situation
on Windows: symbols without DBUS_EXPORT or DBUS_PRIVATE_EXPORT
decoration are internal to libdbus-1, and cannot be used by
other programs, even within the dbus source tree.
This means the compiler/linker can optimize calls to those functions
by avoiding indirection through the PLT, which should improve
performance a little. However, the primary purpose of doing this is
that it means developers building libdbus on Linux are considerably
less likely to break it on Windows by mistake.
I'm deliberately not adding -fvisbility=hidden in CMake because the
complexity of doing so is unnecessary: Autotools is the recommended
way to build dbus for Unix, and the one Unix developers are going
to use in practice, unless they are specifically checking that they
haven't broken the CMake build.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
AppArmor support can be configured at build time with --enable-apparmor
and --disable-apparmor. By default, the build time decision is
automatically decided by checking if a sufficient libapparmor is
available.
A minimum required libapparmor is version 2.8.95.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
[smcv: avoid potential non-portability from "test EXPR -a EXPR"]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
This guide gives some pointers on how to write D-Bus APIs which are nice
to use.
It adds an optional dependency on Ducktype and yelp-build from
yelp-tools. These are used when available, but are not required unless
--enable-ducktype-docs is passed to configure. They are required for
uploading the docs, however.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88994
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We run each test twice:
* once with the system's session.conf, as an integration test
(test-cases that need a special configuration are automatically
skipped)
* once with our special test configuration files, which provide better
coverage
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88810
Reviewed-by: Philip Withnall
This is for g_close(), which the next commit will use. It also lets us
rely on g_type_init() being a no-op (since 2.32 the type system is
always initialized by a global constructor).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88810
Reviewed-by: Philip Withnall
pygobject 2 is obsolete and unmaintained, and anyway this is for
optional functionality (full regression test coverage) rather than
anything that will be needed in production builds.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=85969
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>
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.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76112
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
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=82820
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
