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:
> We might talk past each other, I should have been more precise (also changed
> the subject line accordingly): I am not talking about system and session D-Bus,
> but rather about private DBus connections, taking advantage of the D-Bus
> message infrastructure to allow a mix of computers running Linux, Windows (and
> sometimes MacOSX) interconnected via TCP, which has been possible for a long
> time!

Sorry, private D-Bus connections are a lower priority for the D-Bus
maintainers than the standard system and session buses. We do not have
enough maintainers or time to prioritize everything equally, so our focus
is on the main use cases that are unique to D-Bus: the standard system
bus, and the standard session bus.

There are lots of other RPC protocols suitable for general-purpose
interconnection between machines, and that's OK. I would like to encourage
developers to choose the right tool for the job - sometimes that's D-Bus,
sometimes it isn't.

For example, alternatives for communication within a LAN include ZeroMQ,
nanomsg and Cap'n Proto.

> Ad the argument "not what ... is designed for": sometimes designs are great to
> be applied to use cases, the original developers have not thought about at all
> (or thought they might be interesting, but not important).

Sure, and if we had an unlimited number of maintainers working on D-Bus
full-time, maybe we could spread out our focus like that; but we don't.

The more use cases we try to support, the less time and attention we can
put on each one. Nobody works on D-Bus full-time, so reviewers' available
time and attention is a limited resource. In an ideal world, sure, we'd
have a large community, multiple full-time developers, and the ability to
implement and review large feature requests quickly; but we are not
currently in that world. At the moment it's a struggle to get bug fixes
implemented and reviewed, and the one significant feature that I'm working
on (Containers1) has taken a year so far and is still not done.

I do not have the luxury of being able to invest large amounts of time
in features that do not benefit D-Bus' core use cases. (I wish I did!)

> Just the fact that private DBus connections exist proves that D-Bus was
> designed for leveraging the D-Bus message infrastructure to client-server
> applications with private DBus connections.

(Note that I maintain D-Bus and dbus, but I did not design them; my
involvement began several years after the protocol was first designed.)

Peer-to-peer/private D-Bus connections exist, but have always been
"second class citizens". Many higher-level libraries don't support them
well (or at all).

The concept of a client's identity on D-Bus is tightly coupled to
OS-level users: Unix numeric user IDs on Unix platforms, and Windows
SIDs on Windows. If you dig into the authentication protocol, you'll see
that the claim made by an authenticating Unix client is something like
"I am uid 1000", and the claim made by an authenticating Windows client
is something like "I am SID S-1-5-18". This makes a lot of sense for
the standard system and session buses, where process credentials and
user credentials are essentially the same thing, but makes a lot less
sense in network environments, where you probably have some higher-level
concept of identity, like a TLS certificate, some sort of OS-agnostic
user database, or maybe an IP address (if you can trust clients not to
spoof addresses, or you have out-of-band knowledge that your network
validates addresses and discards spoofed packets, for example if it's
a specially configured VPN).

The ANONYMOUS authentication mechanism was added several years after D-Bus
development started. Using the ANONYMOUS mechanism completely abdicates
responsibility for authentication: anyone who can contact a server can be
ANONYMOUS, and can do anything that ANONYMOUS is authorized to do. This
is rarely a particularly desirable semantic either, because some sort
of access control is usually a good thing; but because ANONYMOUS is
the only authentication scheme we have that is independent of OS-level
users, developers are tempted to use it (either as a "back door" for
testing/debugging, or even in production), and then when they forget to
disable it, we get the Jeep hack.

> 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.

D-Bus-over-TCP was implemented 15 years ago, and nobody has contributed
D-Bus-over-TLS code yet.

Even if someone did contribute D-Bus-over-TLS support now, I'm
not sure that we would want to merge it, because a thorough review
of security-sensitive code takes maintainer time, ongoing support
(fixing bugs) takes maintainer time, and mapping TLS' identity model
onto D-Bus' identity model is far from a trivial thing to do (TLS is
specified in terms of certificates with an X.500 Distinguished Name and
certifying authorities that you might or might not trust, whereas D-Bus
authentication is specified in terms of Unix uids and Windows SIDs).

It's all open source, so if you want to fork under a different name,
go ahead. I believe AllJoyn is is essentially a fork of the D-Bus
specification and an independent implementation of that forked
specification, although I haven't examined it in detail.

GDBus would probably be a better basis for a fork with TLS support than
libdbus, since it already uses GIO streams instead of low-level sockets.

    smcv