How about employing TLS for private DBus connections ? (Re: dbus insecure over secure TCP?
rony at wu.ac.at
Tue Jul 17 11:09:14 UTC 2018
Not knowing what is involved in D-Bus for adding TLS, I thought for those in the know the server and
client code at openssl.org may help assess the complexity:
The downloadable samples, they write, include error checking which was left out for brevity of the
On 16.07.2018 17:22, rony wrote:
> On 14.07.2018 21:32, Thiago Macieira wrote:
>> 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.
> 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!
> Taking advantage of the D-Bus infrastructure via private D-Bus connections for creating services
> and exploiting them on the clients seems to be quite efficient and bears low overhead for the
> application developers employing D-Bus for their communication needs, especially in a mix of
> computers running different operating systems in businesses/organizations within a closed LAN.
>>> 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
>> I don't know which great efforts you're speaking about are. I've never heard
>> of anyone doing that.
> Probably my fault, this is what I meant (https://dbus.freedesktop.org/doc/dbus-tutorial.html):
> " ...cut...
> The bus daemon has multiple instances on a typical computer. The first instance is a
> machine-global singleton, that is, a system daemon similar to sendmail or Apache. This
> instance has heavy security restrictions on what messages it will accept, and is used for
> systemwide communication.
>>> 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
>> 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.
> 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).
> E.g. Linux was not designed for TVs or watches, yet in the meantime Linux gets deployed on such
> devices (and in many other scenarios). Suggesting an improvement to Linux to help it being
> deployed/exploited better or on other than originally envisioned devices then could have been
> easily be turned down with the killer argument "that's simply not what Linux is designed for". In
> fact that has not happened and Linux has been happily running on such - originally - unenvisioned
> devices (with more to be expected in the future). And each new device that runs Linux makes Linux
> more important and more ubiquitous.
> 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.
> Maybe there are shortcomings in this application scenario that I am not aware of and that cause
> the D-Bus developers to step back from supporting private DBus connections in the future?
> ... cut ...
> D-Bus has been allowing D-Bus servers on private D-Bus connections that employ TCP. Just learned
> from <https://dbus.freedesktop.org/doc/dbus-specification.html> that the current plan is to get
> TCP deprecated (what about nonce)?
> 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.
> 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
> For the private D-Bus connection the address parameter for "DBUS_EXPORT DBusConnection *
> dbus_connection_open_private(const char * address, DBusError * error )"  would ideally be the
> only necessary change to existing D-Bus applications in such a case.
> Creating client-server applications exploiting the DBus message infrastructure using private DBus
> connections is a quite powerful means, straight-forward and easy for application programmers. TLS
> for private DBus connections would allow application programmers to (quickly) create and deploy
> DBus server and client applications, intermixing Linux, Windows and MacOSX server/client machines
> in a secure manner.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dbus