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>
Antoine Jacoutot [Wed, 25 Apr 2012 18:04:07 +0000 (19:04 +0100)]
use cp and mkdir -p instead of install within source tree
$(INSTALL) and $(INSTALL_DATA) try to change ownerships to root:bin when
copying tests to builddir. Presumably this is a difference in behaviour
between GNU and BSD install(1): the one in GNU coreutils doesn't try-and-fail
to change ownership if you're not root.
[Commit message added by smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48127 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
David Zeuthen [Thu, 12 Apr 2012 15:16:48 +0000 (11:16 -0400)]
Avoid using monotonic time in the DBUS_COOKIE_SHA1 authentication method
When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.
The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.
First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.
Signed-off-by: David Zeuthen <davidz@redhat.com> Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
David Zeuthen [Thu, 12 Apr 2012 03:05:33 +0000 (23:05 -0400)]
Avoid using monotonic time in the DBUS_COOKIE_SHA1 authentication method
When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.
The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.
First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.
Signed-off-by: David Zeuthen <davidz@redhat.com> Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
Martin Pitt [Mon, 23 Jan 2012 11:11:24 +0000 (11:11 +0000)]
Port to glib 2.31.x g_thread API
g_thread_init() is deprecated since glib 2.24, call g_type_init() instead.
Bump glib requirement accordingly.
g_thread_create is deprecated since 2.31, use g_thread_new() instead. When
building with a glib earlier than 2.31, provide a backwards compatibility shim.
[Added a comment about why we're using g_type_init() in a test that
doesn't otherwise use GObject -smcv]
[Applied to 1.4 despite just being a deprecation fix because it also fixes
linking with GLib 2.32, in which gthread has been removed from gobject's
Requires and moved to Requires.private, Debian #665665 -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=44413
Bug-Debian: http://bugs.debian.org/665665 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The "unixexec:" transport will create a local AF_UNIX socket with
socketpair(), then fork and execute a binary on one side with STDIN and
STDOUT connected to it and then use the other side.
This is useful to implement D-Bus tunneling schemes, for example to get
a D-Bus connection to the system bus on a different host, similar how
udisks is already doing it. (udisks uses SSH TCP tunneling for this,
which is a bit ugly and less secure than this solution).
Suggested use is with connection strings like the following:
The first line would execute the binary 'system-bus-bridge' on host
'foobar' and then pass D-Bus traffic to it. This (hypothetical) bridge
binary would then forward the information to the local system bus.
The second and third line use this scheme locally to acquire a
privileged connection through pkexec resp. sudo: instead of connecting
directly to the bus, they use the same bridge binary which will forward
all information to the system bus.
The arguments of the protocol are 'path' for the first execlp()
argument, and argv0, argv1, and so on for the following arguments. argv0
can be left out in which case path will be used.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Mon, 13 Feb 2012 19:54:52 +0000 (19:54 +0000)]
Make dbus-daemon.exe --print-address work under Windows
The DBusPipe code was broken by commit 6e214b5b3c2837, which switched
from C runtime API to Win32 API for WinCE's benefit. In a DBusPipe,
fd_or_handle is in fact always a C runtime file descriptor, which can't
be used with the Win32 API (which expects a HANDLE).
This commit goes back to the C runtime API. It might cause WinCE support
to regress, but at least dbus-daemon.exe --print-address works again.
This is enough to make a few tests work under Wine when cross-compiling
from Linux to mingw-w64: in particular, this now works:
projects / thirdparty / dbus.git / log
