How about employing TLS ? (Re: dbus insecure over secure TCP?
rony <[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Organization | WU Wien |
| Message-ID | <[email protected]> |
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/> _______________________________________________ dbus mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dbus