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

[rony]

On 22.08.2018 16:56, Simon McVittie wrote:
> 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.
D-Bus was designed with the ability to allow for using it for application programming outside of the
specific use for system and session buses on Linux. This makes sense as it is incredibly easy to
leverage the developed and maintained D-Bus infrastructure to generic client-server application
developments.

In addition the reference implementation of D-Bus has been ported to non-Linux environments which
shows that its applicability is of great value for these other environments as well. Being able to
write multi-platform client-server applications taking advantage of the D-Bus infrastructure is
really a boon.

> The world already has a lot of protocols for machine-to-machine network
> communication, 
Which ones do you suggest that are as easy as D-Bus for creating multi-platform client-server
applications in all those languages that have D-Bus bindings already? D-Bus can be suggested to
small to medium sized companies to fulfill their client-server needs in their (closed) networks.

> so that is a lower priority for D-Bus than its unique role
> in providing "the" system/session bus for Free desktop environments.
It goes without saying that providing "the" system/session bus is very important. However, this is
not a reason that other existing D-Bus features that are specified and implemented just get removed
though.

>> 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.
It would be sufficient already to allow for using a supplied certificate file (instead of a nonce as
a shared secret), which gets distributed to the server and to the clients. To distribute the
certificate safely is a deployment task (to create them is as easy as using the Java "keytool"
utility).

> (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.)
TLS would take care of encryption already.

---rony