Ray Strode [Tue, 16 Oct 2012 18:38:28 +0000 (14:38 -0400)]
dbus-spawn: set SIGPIPE to SIG_IGN before activating services
dbus's service activation code sets SIGPIPE to SIG_DFL as a
sort of poor man's prctl(... PR_SET_PDEATHSIG) to detect when
the parent goes away.
It neglects to reignore the infamous signal before performing
activation, however.
This means if, for instance, journald is restarted all
services activated after it will die with SIGPIPE when logging
messages unless they explicitly ignore SIGPIPE themselves.
This commit changes dbus's service activation code to correctly
ignore SIGPIPE to protect activated services from a gruesome,
premature death.
Reviewed-by: Lennart Poettering <lennart@poettering.net>
https://bugzilla.redhat.com/show_bug.cgi?id=839258
Simon Peeters [Sun, 7 Oct 2012 14:59:30 +0000 (16:59 +0200)]
Set correct address when using --address=systemd:
When dbus gets launched through systemd, we need to create an address
string based on the sockets passed.
The _dbus_append_addres_from_socket() function is responsible for
extracting the address information from the file-descriptor and
formatting it in a dbus friendly way.
This fixes bus activation when running dbus under a systemd session.
Simon McVittie [Tue, 2 Oct 2012 08:34:48 +0000 (09:34 +0100)]
activation helper: when compiled for tests, do not reset system bus address
Otherwise, the tests try to connect to the real system bus, which will
often fail - particularly if you run the tests configured for the default
/usr/local (with no intention of installing the result), in which case
the tests would try to connect to /usr/local/var/run/dbus/system_bus_socket.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=52202
Geoffrey Thomas [Fri, 28 Sep 2012 05:02:06 +0000 (22:02 -0700)]
activation-helper: Ensure DBUS_STARTER_ADDRESS is set correctly
The fix for CVE-2012-3524 filters out all environment variables if
libdbus is used from a setuid program, to prevent various spoofing
attacks.
Unfortunately, the activation helper is a setuid program linking
libdbus, and this creates a regression for launched programs using
DBUS_STARTER_ADDRESS, since it will no longer exist.
Fix this by hardcoding the starter address to the default system bus
address.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com> Signed-off-by: Colin Walters <walters@verbum.org>
Colin Walters [Fri, 28 Sep 2012 14:05:59 +0000 (10:05 -0400)]
hardening: Use __secure_getenv() in *addition* to _dbus_check_setuid()
This is a further security measure for the case of Linux/glibc
when we're linked into a binary that's using filesystem capabilities
or SELinux domain transitions (i.e. not plain old setuid).
In this case, _dbus_getenv () will return NULL because it will
use __secure_getenv(), which handles those via AT_SECURE.
Colin Walters [Fri, 28 Sep 2012 01:29:29 +0000 (21:29 -0400)]
hardening: Use __secure_getenv if available
This helps us in the case where we were executed via filesystem
capabilities or a SELinux domain transition, not necessarily a plain
old setuid binary.
Colin Walters [Wed, 22 Aug 2012 14:03:34 +0000 (10:03 -0400)]
CVE-2012-3524: Don't access environment variables or run dbus-launch when setuid
This matches a corresponding change in GLib. See
glib/gutils.c:g_check_setuid().
Some programs attempt to use libdbus when setuid; notably the X.org
server is shipped in such a configuration. libdbus never had an
explicit policy about its use in setuid programs.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
How to determine whether or not we're running in a privilege-escalated
path is operating system specific. Note that GTK+'s code to check
euid versus uid worked historically on Unix, more modern systems have
filesystem capabilities and SELinux domain transitions, neither of
which are captured by the uid comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-by: Sebastian Krahmer <krahmer@suse.de> Signed-off-by: Colin Walters <walters@verbum.org>
Geoffrey Thomas [Fri, 28 Sep 2012 05:02:06 +0000 (22:02 -0700)]
activation-helper: Ensure DBUS_STARTER_ADDRESS is set correctly
The fix for CVE-2012-3524 filters out all environment variables if
libdbus is used from a setuid program, to prevent various spoofing
attacks.
Unfortunately, the activation helper is a setuid program linking
libdbus, and this creates a regression for launched programs using
DBUS_STARTER_ADDRESS, since it will no longer exist.
Fix this by hardcoding the starter address to the default system bus
address.
Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com> Signed-off-by: Colin Walters <walters@verbum.org>
Colin Walters [Fri, 28 Sep 2012 14:05:59 +0000 (10:05 -0400)]
hardening: Use __secure_getenv() in *addition* to _dbus_check_setuid()
This is a further security measure for the case of Linux/glibc
when we're linked into a binary that's using filesystem capabilities
or SELinux domain transitions (i.e. not plain old setuid).
In this case, _dbus_getenv () will return NULL because it will
use __secure_getenv(), which handles those via AT_SECURE.
Colin Walters [Fri, 28 Sep 2012 01:29:29 +0000 (21:29 -0400)]
hardening: Use __secure_getenv if available
This helps us in the case where we were executed via filesystem
capabilities or a SELinux domain transition, not necessarily a plain
old setuid binary.
Colin Walters [Wed, 22 Aug 2012 14:03:34 +0000 (10:03 -0400)]
CVE-2012-3524: Don't access environment variables or run dbus-launch when setuid
This matches a corresponding change in GLib. See
glib/gutils.c:g_check_setuid().
Some programs attempt to use libdbus when setuid; notably the X.org
server is shipped in such a configuration. libdbus never had an
explicit policy about its use in setuid programs.
I'm not sure whether we should advertise such support. However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.
Better to fix a problem caused by an interaction between two
components in *both* places if possible.
How to determine whether or not we're running in a privilege-escalated
path is operating system specific. Note that GTK+'s code to check
euid versus uid worked historically on Unix, more modern systems have
filesystem capabilities and SELinux domain transitions, neither of
which are captured by the uid comparison.
On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup. If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use. Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1
So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.
On some BSD variants, there is a issetugid() function. On other Unix
variants, we fall back to what GTK+ has been doing.
Reported-by: Sebastian Krahmer <krahmer@suse.de> Signed-off-by: Colin Walters <walters@verbum.org>
Simon McVittie [Mon, 13 Aug 2012 18:57:13 +0000 (19:57 +0100)]
Split DBUS_SESSION_BUS_DEFAULT_ADDRESS into listen, connect addresses and set better defaults
On Unix, the connect address should basically always be "autolaunch:"
but the listen address has to be something you can listen on.
On Windows, you can listen on "autolaunch:" or
"autolaunch:scope=*install-path", for instance, and the dbus-daemon is
involved in the auto-launching process.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38201 Reviewed-by: David Zeuthen <davidz@redhat.com>
[default address changed to autolaunch: for interop with GDBus -smcv] Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Wed, 4 Jan 2012 19:39:54 +0000 (19:39 +0000)]
cmake: use the same default system bus address as for autotools
The system bus is unsupported (and rather meaningless) on Windows anyway,
so we can use anything. Also, make it clear that it has to be a
"specific" address that can be listened on *and* connected to,
like unix:path=/xxx - a listen-only address like unix:tmpdir=/xxx or
nonce-tcp: would not be suitable.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38201 Reviewed-by: David Zeuthen <davidz@redhat.com>
Wolfgang Baron [Wed, 18 Jul 2012 17:09:44 +0000 (18:09 +0100)]
Fix launching of dbus-daemon on Windows in paths containing spaces
If dbus is installed in a path, which contains a space, dbus-launch will
not launch the daemon. That is so, because a command line is built from
just the path to the daemon and a parameter. The path has to be
surrounded with quotes. This can be done unconditionally, because the
quotes do not cause any trouble even if they are not needed.
Colin Walters [Sun, 8 Jul 2012 13:37:09 +0000 (09:37 -0400)]
spec: Mention object path and interface name
We didn't actually have /org/freedesktop/DBus in the spec, nor did we
explicitly mention the existence of "org.freedesktop.DBus" as an
interface, although it is implicit in the method names.
Simon McVittie [Tue, 3 Jul 2012 08:26:27 +0000 (09:26 +0100)]
DBusTransport: do not assert that autolaunch address is non-empty
dbus-launch can apparently return an empty address under certain
circumstances, and dbus_parse_address() in the next line will return
a nice DBusError for an empty address rather than aborting the process.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51657
Bug-Debian: http://bugs.debian.org/680027 Reviewed-by: David Zeuthen <davidz@redhat.com>
Simon McVittie [Mon, 25 Jun 2012 12:26:35 +0000 (13:26 +0100)]
Create /var/lib/dbus explicitly rather than as a side-effect
Since Automake 1.11.4, an empty localstatelib_DATA variable will not
create $(localstatelibdir) as a side-effect.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51406 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Lennart Poettering <lennart@poettering.net>
Simon McVittie [Mon, 25 Jun 2012 11:20:45 +0000 (12:20 +0100)]
dbus_pending_call_set_notify: don't leave the connection locked on OOM
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51032 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Lennart Poettering <lennart@poettering.net>
Simon McVittie [Mon, 25 Jun 2012 10:55:22 +0000 (11:55 +0100)]
Set configure defaults from --enable-developer, not Automake maintainer mode
Automake maintainer mode isn't about whether you're a maintainer or not
(although its name would suggest that), it's about whether files that are
normally distributed in the tarball get regenerated. As such, it's
not really appropriate to use it to drive defaults for things like
assertions and extra test code.
The desired effect is that developers building from git normally get
tests and assertions, while distribution packagers don't.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34671 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: Colin Walters <walters@verbum.org>
Simon McVittie [Mon, 12 Mar 2012 14:15:48 +0000 (14:15 +0000)]
When not producing a dynamic library, define DBUS_STATIC_BUILD
When targeting Windows, linking against the static library requires
special effort to turn off DLL import/export processing. We normally
link some things against the dynamic library, but if we're not building
that, we'll have to link everything statically.
Simon McVittie [Fri, 15 Jun 2012 13:11:50 +0000 (14:11 +0100)]
Cut minor version down to 255
Entertainingly, bits of libdbus assume that one byte is enough for each
version number component (as API!), and one test even fails if this
isn't true.
Simon McVittie [Tue, 7 Feb 2012 17:43:28 +0000 (17:43 +0000)]
Document that dbus-launch is not dbus-run-session
Architectural assumptions inside dbus-launch mean that it is unsuitable
for use in contexts where a particular process's lifetime defines the
session, unless there is an out-of-band mechanism (like the X server)
which can signal the end of the session.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
Simon McVittie [Tue, 7 Feb 2012 17:00:46 +0000 (17:00 +0000)]
dbus-launch: revise recommendations and put them in an EXAMPLES section
The first thing we should talk about is how to get a D-Bus session in
your X session - that's the common case.
Secondarily, we can tell command-line addicts how to have a D-Bus session.
Do not recommend --exit-with-session here, since that polls (and reads
from) stdin, which is harmful to precisely those command-line users!
Until we have some better tool, the best we can do here is note that
the dbus-daemon is not automatically terminated.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
Simon McVittie [Tue, 7 Feb 2012 16:55:05 +0000 (16:55 +0000)]
dbus-launch: if using X to define the session lifetime, do not poll stdin
dbus-launch --exit-with-session attempts to scope the session length
to various things:
- if DISPLAY points to an X server, exit when the X session ends
- if stdin is a terminal, exit when end-of-file is reached
- if both are true, exit when one of them happens, whichever is first
- if neither is true, fail
These are not particularly useful semantics: if the session is scoped to
the X session, then the terminal from which dbus-launch was launched
is irrelevant. This also causes practical problems when dbus-launch
consumes characters from the terminal from which it happens to have
been launched (some display managers, like slim and nodm, run users' X
sessions with stdin pointing to the terminal from which the init daemon
happens to have started the display manager during boot, usually tty1
on Linux).
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
Simon McVittie [Tue, 5 Jun 2012 12:27:23 +0000 (13:27 +0100)]
Fix distcheck: remove potentially-read-only files from builddir
During distcheck, the srcdir is read-only. During "make all", cp may
preserve the read-only status of the file copied from the srcdir,
resulting in failure to overwrite it with an identical file during
"make check" (which depends on all-local).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
projects / thirdparty / dbus.git / log
