We have 16-bit types with 2-byte alignment, but this comment claimed
we only have 1-, 4- or 8-byte alignment. The actual implementation is
fine, and correctly reports 2-byte alignment for the 16-bit types.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We recommend disabling assertions in production builds of dbus, so it
is "cheap" to add them even in relatively fast-path locations.
Signed-off-by: Simon McVittie <smcv@collabora.com>
array_reader_check_finished() no longer returns a type, only a boolean,
so this comment isn't accurate any more.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We already checked that claimed_len <= (end - p), therefore we can
assume that claimed_len + p <= end. Make this a bit more obvious.
Signed-off-by: Simon McVittie <smcv@collabora.com>
MacOS has limited support for monotonic clock in its pthread implementation.
When building with Meson, `HAVE_MONOTONIC_CLOCK` is defined despite this.
This PR checks for the existence of the missing function `pthread_condattr_setclock`.
To match parity with AutoTools, it also checks for `clock_getres`.
Fixes#419.
When a D-Bus message includes attached file descriptors, the body of the
message contains unsigned 32-bit indexes pointing into an out-of-band
array of file descriptors. Some D-Bus APIs like GLib's GDBus refer to
these indexes as "handles" for the associated fds (not to be confused
with a Windows HANDLE, which is a kernel object).
The assertion message removed by this commit is arguably correct up to
a point: fd-passing is only reasonable on a local machine, and no known
operating system allows processes of differing endianness even on a
multi-endian ARM or PowerPC CPU, so it makes little sense for the sender
to specify a byte-order that differs from the byte-order of the recipient.
However, this doesn't account for the fact that a malicious sender
doesn't have to restrict itself to only doing things that make sense.
On a system with untrusted local users, a message sender could crash
the system dbus-daemon (a denial of service) by sending a message in
the opposite endianness that contains handles to file descriptors.
Before this commit, if assertions are enabled, attempting to byteswap
a fd index would cleanly crash the message recipient with an assertion
failure. If assertions are disabled, attempting to byteswap a fd index
would silently do nothing without advancing the pointer p, causing the
message's type and the pointer into its contents to go out of sync, which
can result in a subsequent crash (the crash demonstrated by fuzzing was
a use-after-free, but other failure modes might be possible).
In principle we could resolve this by rejecting wrong-endianness messages
from a local sender, but it's actually simpler and less code to treat
wrong-endianness messages as valid and byteswap them.
Thanks: Evgeny Vereshchagin
Fixes: ba7daa60 "unix-fd: add basic marshalling code for unix fds"
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/417
Resolves: CVE-2022-42012
Signed-off-by: Simon McVittie <smcv@collabora.com>
These environment variables are used by GLib's g_test_build_filename()
and related convenience functions, which make it easier for unit tests
to find data files in a way that works for both build-time tests and
"as-installed" tests. During "as-installed" testing, both variables
will normally be unset, and GLib uses the directory containing the
executable. In most cases that results in the right thing happening, and
this will also be true for dbus, since we install the test executables
in ${libexecdir}/installed-tests, helper executables in the same place,
and test data in ${libexecdir}/installed-tests/data.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In debug builds with "embedded tests" enabled, these will automatically
be used as input for the message-internals test.
Some of the messages themselves are output from a fuzzer, others are
simplifications to include only one reason for lack of validity per
message.
I've included an annotated hex-dump for each message here, but the dbus
test suite doesn't currently know how to convert hex to binary, so I've
also committed the corresponding binary. See the comment at the top of
each hex-dump for how to create the binary version (which requires the
xxd tool shipped with vim).
It would be nice for the dbus test suite to be able to convert the
annotated hex-dump to binary, either at build-time with a Python script
or at runtime by loading the text file and decoding the hex, but I don't
want to block on that for dbus/dbus#413 and dbus/dbus#418.
Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/413
Reproduces: https://gitlab.freedesktop.org/dbus/dbus/-/issues/418
Signed-off-by: Simon McVittie <smcv@collabora.com>
This fast-path previously did not check that the array was made up
of an integer number of items. This could lead to assertion failures
and out-of-bounds accesses during subsequent message processing (which
assumes that the message has already been validated), particularly after
the addition of _dbus_header_remove_unknown_fields(), which makes it
more likely that dbus-daemon will apply non-trivial edits to messages.
Thanks: Evgeny Vereshchagin
Fixes: e61f13cf "Bug 18064 - more efficient validation for fixed-size type arrays"
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/413
Resolves: CVE-2022-42011
Signed-off-by: Simon McVittie <smcv@collabora.com>
In debug builds with assertions enabled, a signature with incorrectly
nested `()` and `{}`, for example `a{i(u}` or `(a{ii)}`, could result
in an assertion failure.
In production builds without assertions enabled, a signature with
incorrectly nested `()` and `{}` could potentially result in a crash
or incorrect message parsing, although we do not have a concrete example
of either of these failure modes.
Thanks: Evgeny Vereshchagin
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/418
Resolves: CVE-2022-42010
Signed-off-by: Simon McVittie <smcv@collabora.com>
On Linux, there are two classes of AF_UNIX socket, which D-Bus refers
to as unix:path=... (portable to non-Linux systems) and unix:abstract=...
(not portable).
Back in 2003 when dbus gained support for abstract Unix sockets on Linux,
everyone thought they were better in every way than path-based Unix
sockets: if a DBusServer crashes or is terminated abnormally, there's
no detritus left in the filesystem. What's not to like? As a result,
since commit a70b042f (2003-06-04), when a DBusServer listens on a
unix:tmpdir=... address on Linux, the default is for the result to be
a unix:abstract=... address, with unix:path=... addresses only used on
non-Linux platforms.
However, the world has changed in the last 19 years, and namespace-based
Linux containers (which didn't exist in 2003) are now very popular. This
makes abstract sockets problematic.
Abstract sockets are tied to the network namespace, which is
all-or-nothing: if a container is to access the Internet without using
some sort of proxy or intermediary (like slirp4netns) then it needs to
share the network namespace with the host system, and that implies
sharing all abstract sockets with the host system. If the well-known
session bus is listening on an abstract socket, then it's a sandbox
escape route for any sandboxed or containerized app running under the
same uid. Conversely, if a container is *not* sharing the network
namespace with the host system, then it cannot access a session bus that
is listening on an abstract socket without using some sort of proxy
(like xdg-dbus-proxy), even if it isn't intended to impose a security
boundary and giving it direct access to the session bus would have been
more desirable.
Path-based sockets do not have this problem because they exist in the
filesystem (part of the "everything is a file" Unix philosophy),
allowing mount namespaces and bind-mounts to be used to share or
unshare them selectively.
On systems with `systemd --user` where dbus has been configured with
`--enable-user-session`, in general the session bus will already be
using a path-based socket for the "user bus", disregarding the listening
address specified in /usr/share/dbus-1/session.conf. The default in many
recent Linux distributions is either to use dbus-daemon in this way, or
to use dbus-broker, a reimplementation of the message bus service which
has similar "user bus" behaviour.
However, the <listen> address in session.conf is used when dbus-launch(1)
or dbus-run-session(1) is used to start a session bus, either manually,
via autolaunching, or via system integration glue in operating systems
that are not using `systemd --user`. This will occur particularly often
in operating systems that boot using a non-systemd init system.
Making unix:tmpdir=/tmp equivalent to unix:dir=/tmp ensures that the
well-known session bus listens on a path-based socket, allowing container
and sandboxing frameworks to mediate access to it in the same way they
would for the user bus. The D-Bus Specification already allows (but does
not require) this behaviour, because it is the only thing that was
implementable on non-Linux systems such as *BSD.
This change has the potential to cause regressions. If a container
framework enters a chroot or unshares the mount namespace but does not
unshare the network namespace, and is relying on the ability for a
process inside a container to access the session bus outside the
container via its abstract socket, then that assumption will be broken
by this change. Some use cases of schroot(1) are likely to suffer from
this. However, container frameworks with that assumption would already
have found that it does not hold when using the user bus, and it is
necessary to break that assumption if we want it to be possible to apply
application-level sandboxing in a secure way.
Another potential regression from this change is that if a dbus-daemon
is terminated abnormally, it will leave a socket in /tmp. Distributors
of operating systems where heavy use of dbus-launch(1) is expected might
wish to run dbus-cleanup-sockets(1) periodically.
This partially reverts commit a70b042f.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/416
Signed-off-by: Simon McVittie <smcv@collabora.com>
I am building DBus targeting the Arm Morello board and the "no padding"
layout assertion fails here since pointers require 16-byte alignment, and
therefore we have to add two additional ints to the DBusMessageIter struct.
As this is a new architecture, where DBus previously failed to compiled
we do not have any layout backwards compatibility requirements, so we can
simplify the DBusMessageIter structure to allocate space for 16 pointers
(which should give us a lot of space for any further changes).
These static assertions fail on CHERI-enabled architectures such as Arm
Morello, where pointers are 128 bits. Architectures with 128-bit pointers
were not supported in DBus 1.10, so we can skip the checks for DBus 1.10
structure layout compatibility for architectures with pointer size > 64 bit.
When building for Arm Morello (where pointers are 16 bytes), I hit the
static assertion that sizeof (DBusMessageRealIter) <= sizeof (DBusMessageIter)
inside _dbus_message_iter_init_common() otherwise. This can be fixed by
moving the pointers to the beginning of the struct to remove padding.
This is required e.g. for CHERI-enabled targets such as Arm Morello where
aligning to sizeof(long) is not sufficient to load/store pointers (which
need 16 byte alignment instead of 8 bytes).
As we can't depend on C11 yet, this commit adds a max_align_t emulation
to dbus-internals.h.
When targeting CHERI-enabled architectures such as Arm Morello, performing
a bitwise and with uintptr_t values can result in an ambiguous operation
compiler warning. Fix this warning by telling compiler which operand is
(potentially) a pointer and which one is an integer by changing the
boundary type to size_t. This change has no functional effect on other
architectures but is required to build with -Werror for Morello.
Example warning message:
```
warning: binary expression on capability types 'unsigned __intcap' and 'unsigned __intcap'; it is not clear which should be used as the source of provenance; currently provenance is inherited from the left-hand side [-Wcheri-provenance]
_dbus_assert (_DBUS_ALIGN_VALUE (insert_at, 8) == (unsigned) insert_at);
```
FreeBSD 13.0 has reached EOL and it appears packages
are built against a newer baseline now, so we end up
with missing symbol errors:
ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found
It also appears that the fdpass test still fails on 13.1, so update the
condition to less than 14.0
Simon McVittie
Kai A. Hiller
Evgeny Vereshchagin
Jordan Williams
Alex Richardson