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

Simon McVittie smcv at collabora.com
Wed Apr 11 15:36:43 UTC 2018


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. The valid
use cases for a dbus-daemon listening on TCP are:

* via the loopback interface (127.0.0.1 or ::1) on Windows;

* on a totally trusted LAN in conjunction with NFS-shared home
  directories on Unix (but in 2018 I don't think this is really valid
  any more, because LANs that you can totally trust are increasingly rare)

If you are using the ANONYMOUS authentication mechanism, that is doubly
insecure. I am seriously considering removing <allow_anonymous/> from
the dbus-daemon: it might occasionally be valid for "peer to peer" D-Bus,
but it is not a reasonable thing to do for a dbus-daemon.

Exposing D-Bus over TCP and enabling ANONYMOUS authentication were
among the factors that led to a recall of 1.4 million unsafe vehicles:
<http://www.bbc.co.uk/news/technology-33650491>.

> Could someone please advice what i need to tune to get back method
> monitoring via dbus-monitor remotely using dbus 1.12.6?

Access the machine remotely by any mechanism of your choice (I'd
recommend Secure Shell or a locally-attached serial console, but something
like telnet would also work if you don't care about security) and run
dbus-monitor that way.

To monitor the system bus, you will need to be either root (uid 0) or
the uid that is running the system bus (usually named messagebus or
dbus, but it depends on your OS distribution). To monitor a session
bus, you need to be the same uid that is running the session bus.

Before dbus 1.11.14, it was possible to configure the system bus to
allow legacy eavesdropping, but only by making it insecure (in ways
that allow local users, and possibly remote users when using TCP,
to escalate privileges). From 1.11.14, legacy eavesdropping does not
work for users other than uid 0 and the owner of the dbus-daemon
process, even if you have configured your system bus insecurely.
(This was part of <https://bugs.freedesktop.org/show_bug.cgi?id=101567>)

Legacy eavesdropping was replaced by the new Monitoring interface in dbus
1.9.10 (2015) and was deprecated in 1.10.0 (also 2015).  The Monitoring
interface was never available to users other than uid 0 and the owner
of the dbus-daemon process. If you are a different uid or ANONYMOUS,
you should see a warning from dbus-monitor when it tries and fails to
enable Monitoring.
(This was <https://bugs.freedesktop.org/show_bug.cgi?id=46787>)

Please could someone with Ubuntu wiki access edit
https://wiki.ubuntu.com/DebuggingDBus to stop recommending an insecure
configuration, at least for Ubuntu 16.04 and later? On dbus 1.10+
(Ubuntu 16.04/xenial or later) the instructions for the system bus can
be simplified to: "Run sudo dbus-monitor --system".

    smcv


More information about the dbus mailing list