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

[Thiago Macieira]

On Saturday, 14 July 2018 07:24:16 PDT rony wrote:
> 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.

Fair enough.

Please understand that opening an unauthenticated and unencrypted TCP port for 
either well-known D-Bus bus, you're basically saying the entire network is 
part of the same system and ALL processes running in it, in any node connected 
to it, have the same privilege rights.

If you're comfortable with that, go right ahead.

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

I don't know which great efforts you're speaking about are. I've never heard 
of anyone doing that.

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

Correct. If you're comfortable with unauthenticated and unencrypted 
connections, you can use this. As you said, the security must come from the 
lower layer.

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

We do, we just don't consider it the main focus or effort. That is why TLS not 
implemented. That's simply not what D-Bus is designed for.

If you want that, I recommend using the "D-Tube" functionality inside 
libdbus-1 that allows you to get a DBusMessage from a byte stream and also 
write a byte stream from a DBusMessage. How you transmit and receive those 
bytes is then up to you. But even that functionality is limited, as we've 
never written the code to initialise a DBusConnection (much less a bus 
connection) without the handshake protocol, for which there is no "D-Tube"

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

That's called AllJoyn. It has been done and is about a decade old.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center