Re: "dbus-monitor --system" stopped monitoring method calls remotely

On Wed, 11 Apr 2018 at 16:36:43 +0100, Simon McVittie wrote:
> On Wed, 11 Apr 2018 at 17:44:58 +0300, Oleg Kuznecov wrote:
> > I have a problem: after dbus upgrade from 1.10.6 to 1.12.6, dbus-monitor
> > stopped  monitoring  method calls if try to monitor remote mashine via TCP/IP.
> > Displays only signals.
> 
> Never use D-Bus remotely via TCP. It has no network-level security,
> making it vulnerable to eavesdropping and unauthorized access.

One thing for which people sometimes (ab)use D-Bus over TCP is this
scenario:

* some service and some client run on an embedded device
* debugging the client on the embedded device is inconvenient
* a developer wants to run a local build of the client on their
  workstation and connect it to the service on their embedded device

Using <listen> or --listen to make the dbus-daemon listen on TCP for this
purpose should be considered dangerous.

The correct way to do this is to set up a tunnel using ssh, socat or a
similar relaying tool, which makes it explicit that the security (or lack
of security) of this relaying is entirely the developer's responsibility.

Since version 1.5.12, dbus has supported a unixexec: transport which is
very convenient for this:
<https://bugs.freedesktop.org/show_bug.cgi?id=35230>. systemd provides a
tool, systemd-stdio-bridge, designed to be used as a unixexec relay.
For example, you can connect a client on the workstation to the dbus-daemon
on the embedded device like this:

dbus-monitor --address "unixexec:path=ssh,argv1=root%40embedded-device,argv2=systemd-stdio-bridge"

or by passing that address to APIs like
g_dbus_connection_new_for_address() or dbus_connection_open_private(). You
can also make a client process connect to the embedded device's
system bus whenever its own system bus is requested, by setting the
DBUS_SYSTEM_BUS_ADDRESS environment variable.

When connecting like this, the client will be acting with the privileges
of whatever user ran the systemd-stdio-bridge process, for example root
in my dbus-monitor example above (because I used root@embedded-device
as the argument to ssh).

Note that like all D-Bus addresses, special characters
such as @ in the parameters of unixexec: addresses
must be escaped in the same way you would for HTTP (%xx). For example,
unixexec:path=ssh,argv1=root%40embedded-device,argv2=systemd-stdio-bridge
runs the equivalent of the shell command-line
'ssh root@embedded-device systemd-stdio-bridge'.

    smcv
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus