I am using network namespaces such that I can capture network traffic of a single process. The namespace is connected through the “host” via a veth pair and has network connectivity through NAT. So far this works for IP traffic and named Unix domain sockets.
A problem arises when a program needs to communicate with the D-Bus session bus. The D-Bus daemon listens on an abstract socket as specified with this environment variable:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jIB6oAy5ea,guid=04506c9a7f54e75c0b617a6c54e9b63a
It appears that the abstract Unix domain socket namespace is different in the namespace. Is there a way to get access to this D-Bus session from the network namespace?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Linux network namespace ip-netns does separate the unix socket and as dbus uses it, it’s then not accessible from the new namespace, we could imagine a feature that would leave access to unix socket but this is not implemented as of 05/2019. Unix socket can be watched with netstat -a -p --unix
Alternative solution using socat to proxy the dbus socket, this is detailed on this answer and here
Alternative solution depending on the needed communication with dbus a new session bus instance can be created with dbus-launch from inside the namespace with dbus-launch my-command-or-app note that other ways can be used like dbus-run-session
Alternative solution netns-exec can run an application/command on a namespace without root access (similar to what firejail can do) but it also can proxy the dbus with socat like the first solution in an automated way and without root access.
Alternative solution xdg-dbus-proxy can also do the job without root and with many additional options like filtering… this could be the best option regarding security if you want to allow access to a single dbus location, this application start being distributed on major distro as it’s part of firejail so building from source may not be required, the man page can be found here or just man xdg-dbus-proxy if the app is installed, here is how to use it:
On the host: xdg-dbus-proxy $DBUS_SESSION_BUS_ADDRESS /tmp/proxybus or xdg-dbus-proxy $DBUS_SESSION_BUS_ADDRESS /tmp/proxybus --filter --talk=org.foo.bar --see=org.gtk.* --own=org.my.name
And on the namespace: DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/proxybus app-using-dbus
Method 2
Connecting to a DBus daemon listening on an abstract Unix socket in a different network namespace is not possible. Such addresses can be identified in ss -x via an address that contains a @:
u_str ESTAB 0 0 @/tmp/dbus-t00hzZWBDm 11204746 * 11210618
As a workaround, you can create a non-abstract Unix or IP socket which proxies to the abstract Unix socket. This is to be done outside the network namespace. From within the network namespace, you can then connect to that address. E.g. assuming the above abstract socket address, run this outside the namespace:
socat UNIX-LISTEN:/tmp/whatever,fork ABSTRACT-CONNECT:/tmp/dbus-t00hzZWBDm
Then from within the namespace you can connect by setting this environment variable:
DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/whatever
Method 3
Linux network namespace only cover network resources, such as IPv4 and IPv6 stacks, network interfaces, IP addresses, IP routes, … But, unix sockets do not belong to network namespaces. Sockets use the filesystem as their adress space, so they are related, if you may even call it so, to mount namespaces to access them thorough the file system. Yet, you can pass unix sockets around by file descriptors, even when no shared mount points are available.
In consequence, DBus communication doesn’t relate to Linux network namespaces, and isn’t affected by it. So, there is no way to access DBus from a network namespace (because that doesn’t apply).
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0