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

Thu Aug 2 17:03:26 UTC 2018

Simon,

firstly, thank you very much for taking the time, consideration and open words, I really appreciate it!

Not being able to contribute directly to D-Bus for time/resource reasons I am not able to contribute
TLS for private D-Bus connections, which I think would benefit everyone who a) is acquainted with
programming D-Bus and b) has a need for client-server-applications (especially in a mixed environment).

It is amazing how simple and powerful such private D-Bus implementations can be.  Private D-Bus
connections help to cut down programmatic overhead needs for D-Bus acquainted programmers in
client-server-scenarios considerably, they have the potential to put SOAP into shade. (Creating SOAP
client-server apps is quite elaborate, creating private D-Bus connections is almost trivial for
D-Bus acquainted programmers.)

It is understandable that you do not want badmouthing to take place against D-Bus, if the reason for
security problems are programmers who do not expect security problems when doing unauthenticated
messaging (like the car-related exploit that, I think you pointed at some years ago). Rather than
removing an important feature because of such a fear that it might be abused/exploited if not
deployed as the D-Bus authors document and advise, it would be better to offer an easy to use
alternative that makes it safe. Then the D-Bus developers can point at the proper application of
private D-Bus connections in (potentially) risky environments. That is the reason why I brought up
TLS that would solve this problem as far as I can see.

---

Ad your hints to turn either away from D-Bus or use alternate packages: I am afraid I would not want
to advise to do that at all as D-Bus is already there and doing what is needed with the sole
exception of a secured transport in the case of private D-Bus connections!

- forks of D-Bus, AllJoins et.al: it is clear that the reference implementation of the D-Bus
specification itself gets maintained and is available on Linux turf for immediate exploitation to
applications; also its Windows and MacOSX implementations are available and maintained; the ability
of private D-Bus connections has been among the specification, therefore available in the reference
implementation and expecting it to remain available; becoming dependent on a yet another variation
of D-Bus or an entire different package, without knowing whether it will be available in the future,
developed, maintained, seems to be quite risky;

- forking GDBus: first, GDBus is yet another package and it is not clear where beyond Linux
(Windows, MacOSX?) and how (APIs, running in non-GUI environments, et.al.?) it can be used and how
long its maintenance will be guaranteed; therefore it adds another dependency that might be risky.

Of course, others may see the risk of a "dependency hell" differently.

---

My hope has been that adding TLS would not be too difficult. But even if someone comes along trying
to add TLS, it seems, that you would not want to support it? IMHO for private D-Bus connections I do
not see the potential problems you mention like "... mapping TLS' identity model onto D-Bus'
identity model is far from a trivial thing to do ...", where I maybe just lacking the knowledge why
such a mapping would be needed between the two, when the task to solve at hand is to make sure that
the communication among the private D-Bus connected clients occurs in a secure way, which could be
realized in a transparent manner for private D-Bus connections using the industry proven TLS?

Maybe you and other D-Bus gurus underestimate the high potential of applications of the private
D-Bus connection if its communication could be secured via TLS, such that one can mix Linux, Windows
and MacOSX computers in companies/organizations and have them communicate using the proven D-Bus
infrastructure even in the open wild, if necessary. (Currently one can mix and run them in closed
LANs quite safely as private D-Bus connections have nothing to do with session- and/or system-buses
in these scenarios.)

As hinted above, creating ad hoc client-server-apps using private D-Bus connections is really
surprisingly easy and efficient by taking advantage of what D-Bus offers (like querying the
interfaces, interacting with messages carrying strictly typed arguments, etc.) for D-Bus programmers.

---rony

On 01.08.2018 15:44, Simon McVittie wrote:
> 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
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dbus