Change default session bus address to use non-abstract sockets
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, 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 --userwhere 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 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.
Changing the default address from unix:tmpdir=/tmp 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.
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.
Distributors wishing to achieve the equivalent of this change without code changes can do so by passing the option --with-dbus-session-bus-listen-address="unix:dir=/tmp" to ./configure, or using the equivalent options in the CMake and Meson build systems.
Resolves: #416 (closed)
tests: Use path-based AF_UNIX sockets in most places
As noted in a previous commit, path-based AF_UNIX sockets are more desirable than abstract sockets in the presence of Linux namespace-based containers. Use the unix:dir=... listenable address in the unit tests, to avoid the unit tests becoming a potential sandbox escape vector.
The one exception is that in test/loopback.c (which is not a full message bus, only a lower-level DBusServer), we continue to have test coverage for both unix:dir=... and unix:tmpdir=... to check that they both work as intended.
Helps: #416 (closed)
spec: Suggest unix:dir=... as preferable to unix:tmpdir=...
Helps: #416 (closed)
I think we want all of this for %1.16.0.
I think we probably also want the first commit of this for %1.14.x, and maybe the second commit too?
For 1.12.x (which is the old-stable branch and is documented as basically security fixes only), I'm not sure whether it's better to pick the first commit of this, or leave it up to distributors whether they want to risk regressions by changing the build-time configuration.