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

[rony]

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/20180716/a6fb709c/attachment.html>