How about employing TLS for private DBus connections ? (Re: dbus insecure over secure TCP?

[Simon McVittie]

On Mon, 16 Jul 2018 at 17:22:38 +0200, rony wrote:
> It seems to me that if security was a concern in such a deployment scenario,
> rather than deprecating the (cross-platform) TCP it would be beneficial for
> D-Bus to allow TLS to be employed for private DBus connections.

Sorry, the maintainers of the reference implementation cannot justify
the time and effort that would be required to do this. We cannot support
every possible use of D-Bus, because we have limited time available. The
more work we put into making D-Bus suitable for uncommon use cases,
the less time we can spend on the things it's designed for.

The world already has a lot of protocols for machine-to-machine network
communication, so that is a lower priority for D-Bus than its unique role
in providing "the" system/session bus for Free desktop environments.

> Whether a handshaking protocol is needed and/or the local path to an accessible
> certificate (keystore) file on the server and the client machine must be
> supplied, would depend on such an implementation.

Trust management is a huge part of deploying TLS: if you don't have a
way to validate the certificate presented by the other peer, then you're
trivially vulnerable to active (man-in-the-middle) attacks. What does it
mean for a certificate to be valid for a particular D-Bus server address?
Which certificate authorities' signatures are acceptable? These are
really quite fundamental questions, and you can't hope to interoperate
without agreeing on answers. These are also questions that I am not able
to spend time answering.

(There is also an implementation issue here: libdbus theoretically
supports SASL mechanisms in which the bytes sent by the application are
modified by a lower layer (e.g. encrypted or authenticated), but none of
the mechanisms we currently have make use of that feature, so it has
never been tested and probably doesn't actually work.)

    smcv