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

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:

  * <https://wiki.openssl.org/index.php/Simple_TLS_Server>
  * <https://wiki.openssl.org/index.php/SSL/TLS_Client>

The downloadable samples, they write, include error checking which was left out for brevity of the
examples.

---rony

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
>>> say.
>> 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.
>     ...cut..."
>
>>> ---
>>>
>>> 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.
> 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
> implementation.
>
> For the private D-Bus connection the address parameter for "DBUS_EXPORT DBusConnection *
> dbus_connection_open_private(const char * address, DBusError * error )" [1] 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.
>
> ---rony
>
> [1]
> <https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga434e3fc7ee420fd30e2f05e57ff26b1d>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20180717/3a011a03/attachment-0001.html>