- Oct 05, 2022
-
-
Simon McVittie authoredSigned-off-by:Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: -
Simon McVittie authored
Reproduces: #417 Signed-off-by:
-
Simon McVittie authored
Signed-off-by:
-
Simon McVittie authored
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: #417 Resolves: CVE-2022-42012 Signed-off-by:
-
Simon McVittie authored
Unlike the message-internals test, these do not rely on extra debug instrumentation in libdbus, and so can be used for "as-installed" testing. (However, they do require GLib.) Reproduces: #413 Reproduces: #418 Signed-off-by:
-
Simon McVittie authored
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 authored
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 #413 and #418. Reproduces: #413 Reproduces: #418 Signed-off-by:
-
Simon McVittie authored
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: #413 Resolves: CVE-2022-42011 Signed-off-by:
-
Simon McVittie authored
Reproduces: #418 Signed-off-by:
-
Simon McVittie authored
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: #418 Resolves: CVE-2022-42010 Signed-off-by:
-
- Oct 02, 2022
-
-
Simon McVittie authored
Signed-off-by: -
Simon McVittie authored
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: #416 Signed-off-by:
-
- Sep 26, 2022
-
-
Simon McVittie authored
Signed-off-by: -
Simon McVittie authored
Signed-off-by: -
Simon McVittie authored
Result of: make -C $builddir update-authors Signed-off-by:
-
- Sep 22, 2022
-
-
Simon McVittie authored
We're not going to replace deprecated functions here, similar to commit 88e0ccb2 in the dbus-1.10 branch. Signed-off-by:
-
- Sep 13, 2022
-
-
Simon McVittie authored
Backport various fixes from 1.15.x branch See merge request dbus/dbus!341
-
Simon McVittie authored
Signed-off-by: -
Commit 97bdefd4 move the include(FindPkgConfig) call into a Linux-specific codepath, so pkg-config was not being detected on FreeBSD. This mean that the check for PKG_CONFIG_FOUND to determine whether to install .pc files later on would always fail and .pc files were not installed on FreeBSD. (cherry picked from commit 82f5c966) Backported-from: dbus!280
-
This was not being checked, so the codepaths using the define were never included. (cherry picked from commit dafb5ddc)
-
This should be the last warning that is preventing us from using -Werror for FreeBSD builds. (cherry picked from commit 2480181a) Backported-from: dbus!307
-
Provided by Dawid Wróbel at https://invent.kde.org/packaging/craft-blueprints-kde\ /-/blob/master/libs/dbus/0002-fix-macos-build.diff (cherry picked from commit 30426b26) Backported-from: dbus!287
-
This header is GCC specific header that on my system just contains `#include_next <limits.h>`. FreeBSD also provides this header but it contains a `#warning` that it should not be used. Replace the one use with `#include <limit.h>` and drop the configure checks. (cherry picked from commit a214ed82) Backported-from: dbus!280
-
Simon McVittie authored
In other projects I've found that having a separate file that only lists the release steps makes them easier to check. Signed-off-by:
-
Simon McVittie authored
In a Linux user namespace, it is possible that we are uid 0 but are unable to switch to some other uid like DBUS_USER or DBUS_TEST_USER, because the other uid is not "mapped" in the user namespace, resulting in setuid() or setresuid() failing with EINVAL "Invalid argument". For example, it's easy for this to happen when running under the bubblewrap tool. Try to drop privileges in a child process, and skip the test if we are unable to do so. Resolves: dbus#407 Signed-off-by:
-
Simon McVittie authored
If we're running in a sandbox, we might not have write access to oom_score_adj. In the common case where we don't have any special protection from the OOM-killer, we can detect that with only read access, and skip the part where we open it for writing. (We would also not have write access to oom_score_adj if we're running with elevated Linux capabilities while not root, but that should never actually happen for dbus-daemon-launch-helper, which is setuid root for production use or has no capabilities during unit-testing.) Signed-off-by:
-
Simon McVittie authored
_dbus_warn() normally only logs a warning, but can be made fatal by environment variables. In particular, we do that during unit testing, which can result in a build-time test failure if dbus is built in a sandbox environment that prevents write access. _dbus_log() does only the logging part of _dbus_warn(), which seems more appropriate here. Signed-off-by:
-
Simon McVittie authored
We are trying to be consistent about saying this codebase is dbus (a piece of software), which is the reference implementation of D-Bus (a protocol). Signed-off-by:
-
Use of exit() requires a stdlib.h include. This check was failing for me since the compiler defaulted to -Werror=implicit-function-declaration, so __sync_sub_and_fetch() support was not dectected. (cherry picked from commit 56e52a42) Backported-from: dbus!320
-
It will have whatever paths the person who built the dist tarball hardcoded. (cherry picked from commit dcd19cc0) Backported-from: dbus!317
-
dbus-sysdeps-unix.c checks for DBUS_USE_SYNC using 0/1 checks not defined checks, so we should be using #cmakedefine01. This fixes lots of -Wundef warnings when compiling for FreeBSD and ensures that we actually use atomics instead of the pthread fallback there. (cherry picked from commit b932c343) Backported-from: dbus!306
-
Without this running, dbus-daemon with long XDG_DATA_DIRS will crash on out-of-bounds write: $ XDG_DATA_DIRS=$(seq -f "/foo/%g" -s ':' 129) dbus-daemon --session *** stack smashing detected ***: terminated (cherry picked from commit b551b3e9) Backported-from: dbus!302
-
We always install to a dbus-1 subdir, but the path encoded in the binary was missing the dbus-1/ subdirectory, so we end up getting errors when trying to load it. (cherry picked from commit f4876e7c) Backported-from: dbus!297
-
Since that commit the error variable is used in all cases not only the DBUS_BUILD_X11 #ifdef branches. Fixes: dbus/dbus#392 (cherry picked from commit 6c1c7e53) Backported-from: dbus!298
-
Simon McVittie authored
<dbus/dbus-arch-deps.h> is architecture-dependent, and compilers have not traditionally supported an installation path for architecture-specific headers (Debian-based systems have /usr/include/${multiarch_tuple}, but that isn't portable beyond Debian). When dbus was built using Autotools, dependent projects that use CMake need to look for this header in the right place. Unfortunately, it seems that at least recent versions of CMake will ignore the HINTS we get from pkg-config if they are told to search in a non-standard prefix via ${DBus1_ROOT}. Look for dbus-arch-deps.h in a directory derived from the filename of the CMake config file, before trying the normal search algorithm. The CMake config file is in ${libdir}, and so is the architecture-specific header, so this should work reasonably reliably. According to the CMake documentation, if we search for the same thing multiple times, the first successful result will be used; and searching with NO_DEFAULT_PATH is the official way to prepend things to the search order. Resolves: dbus/dbus#314 Signed-off-by: -
If /proc/self/oom_score_adj does not exist, fd will invalid (-1). Attempting to set the CLOEXEC flag will obviously fail, and we lose the original errno value from open(). Bug: https://bugs.gentoo.org/834725 Signed-off-by:
Mike Gilbert <floppym@gentoo.org> (cherry picked from commit 769a0462) Backported-from: dbus!285
-
Inferring it from the environment is not correct, since the host system could have a different temporary directory defined. Instead of guessing based on the host, require the user to pass an explicit directory when cross-compiling. This is helpful for me since I am cross-compiling for FreeBSD from macOS and on my host TMPDIR is set to /var/folders/<random characters>/T/ instead of the expected /tmp. (cherry picked from commit e8273099) Backported-from: dbus!279
-
The macOS linker does not accept --export-dynamic, so use this alternate spelling. (cherry picked from commit c7f6d072) Backported-from: dbus!278
-
Otherwise we get the following warnings when building .o files with Clang: clang-13: warning: -Wl,--export-dynamic: 'linker' input unused [-Wunused-command-line-argument] This is required to allow the -Werror build to pass on FreeBSD. (cherry picked from commit 1a8fd7a3) Backported-from: dbus!278
-
