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

[L A Walsh]

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. 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)
>   
----  
    Lans that only only have secure connections to them, such as ssh
or vpns, are 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.
>   
---
    Why
> 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>.
>   
----
    Vehicles are a poor comparison to a stationary, closed environment.
    Especially, since vehicles almost never (maybe never?) use a wired
connection on a closed network. 

>   
>> 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.
>   
---
    You don't use access lists or standard unix/linux access mechanisms?

    Is this a case of moving toward users having to run as root more often
to do anything useful?...i.e. moving toward windows XP level security?

    Linux has had more granular security for some time, and it sounds
like dbus security is going backwards in security?  Don't you honor
group-access security, for example?


> 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>)
>   
---
    And it sounds like there is another requirement to run as root and
have access methods use SUID root ... this is well known to be an insecure
method compared to more granular security methods available .

   
> 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".
>   
---
    Might as well suggest:

    # chmod u+s dbus-monitor

Seems that's going to be the new user interface.

    why bother to use granular privileges when you suggest
dbus only run via an suid root program like 'sudo'?