How about employing TLS ? (Re: dbus insecure over secure TCP?

rony rony at wu.ac.at
Sat Jul 14 14:24:16 UTC 2018


On 14.07.2018 07:17, Thiago Macieira wrote:
> On Friday, 13 July 2018 10:33:32 PDT L A Walsh wrote:
>> Why?  If the TCP-PATH between systems is secure, how is dbus insecure?
> It's not. The point is that the networks are usually not secure, which means 
> you open glaring security holes into your machine by opening the system or 
> session well-known buses via TCP.
The important assumption here is "usually". However, there are plenty of organizations/businesses
that are able to deploy secured networks.

It seems that usually the focal point in these security comments are D-Bus daemons on a single Linux
machine, where great efforts have been put in place to make deploying system and session D-Bus
daemons secure in an open network environment, which in today's world is very important, needless to
say.

---

Turning to another aspect of D-Bus that seems to have been overlooked in many discussions: D-Bus can
also be used to create private D-Bus servers, which is a *very* easy, straight forward process. If a
network is secured in an organization, then one can safely take advantage of it for server-client
applications within an entire network!

As a proof of concept that private D-Bus implementations can be easy and are very helpful
application for any kind of client/server problem, the four slides from page 32 in the presentation
at [1] demonstrate an ooRexx (a dynamically typed, easy to learn language [2]) class implementing
services and a D-Bus client exploiting it.

While developing the D-Bus bindings for ooRexx (cf. [3], [4]) I came up with test applications,
where a private D-Bus server in ooRexx would run on Windows, Linux or MacOSX serving D-Bus clients
running on Windows, Linux and MacOSX via TCP concurrently!

In effect, I speculate that the D-Bus developers and maintainers do not realize the potential this
would allow for, otherwise support for TLS would have been created and made available for the D-Bus
reference implementation.

To stress this point a little bit more: if it was possible to use private D-Bus servers over TLS
(e.g. [5], [6], [7]), then D-Bus would be a dynamite infrastructure for creating powerful
client-server applications in an easy, straight-forward and fast manner for all kinds of
client-server application needs over the entire web, no matter in which language and on which
operating systems the servers or clients execute! (It would probably put SOAP and REST into the
shade in many respects.)

---rony

[1] <http://www.rexxla.org/events/2016/presentations/201608-dbusoorexx.pdf>
[2] <http://wi.wu.ac.at/rgf/rexx/misc/ecoop06/ECOOP2006%5fRDL%5fWorkshop%5fFlatscher%5fPaper%2epdf>
[3] <http://wi.wu.ac.at/rgf/rexx/orx22/201112%2dDBus4ooRexx%2darticle%2epdf>
[4] <http://events17.linuxfoundation.org/sites/events/files/slides/20151006-dbusoorexx-lce_0.pdf>
[5] <https://www.hostingadvice.com/how-to/tls-vs-ssl/>
[6] <https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols>
[7] <https://kinsta.com/blog/tls-1-3/>




More information about the dbus mailing list