12

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?

2
  • 1
    I suspect you can't. Interesting. Commented Oct 5, 2017 at 0:49
  • i added an answer with many interesting alternatives... ;)
    – intika
    Commented May 25, 2019 at 18:10

3 Answers 3

6

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

2
  • Unfortunately none of the alternative solutions are (significantly) better than/different from the current approach. Creating a new dbus session would not help when using an existing DBus service (think of PulseAudio). netns-exec with dbus is the same as my current socat-based solution (except that netns-exec uses setuid root instead of sudo). xdg-dbus-proxy is basically a fancy replacement for socat as it creates a named Unix socket on the filesystem.
    – Lekensteyn
    Commented May 26, 2019 at 19:27
  • Yes indeed they are all the same solution/idea with different implementations; something at the kernel-level + ip-netns would be much better solution but it's not implemented... at least the different possibilities are documented here :)
    – intika
    Commented May 26, 2019 at 23:43
5

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
0
-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).

3
  • 2
    From unix(7): "Linux also supports an abstract namespace which is independent of the filesystem."
    – Lekensteyn
    Commented Jun 25, 2018 at 22:40
  • If you take the time to read my original answer, you'll notice that I note that unix sockets are not covered by Linux network namespaces. Period. That is still correct, despite downvoting. And fs-related unix sockets still relate to the Linux mount namespace. You can easily check this.
    – TheDiveO
    Commented Jun 1, 2019 at 15:58
  • 1
    Downvotes are not mine. I did read your answer, but it is oblivious of the existence of abstract unix domain sockets. My question was not about named Unix sockets on a filesystem. Did you read the (unix(7)) manual I referred to? And network_namespaces(7), saying "In addition, network namespaces isolate the UNIX domain abstract socket namespace (see unix(7))."
    – Lekensteyn
    Commented Jun 10, 2019 at 21:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .