<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 14.07.2018 21:32, Thiago Macieira wrote: <blockquote type="cite" cite="mid:8561045.yQd23Hn1zq@tjmaciei-mobl1"> <pre wrap="">On Saturday, 14 July 2018 07:24:16 PDT rony wrote: </pre> <blockquote type="cite"> <pre wrap="">On 14.07.2018 07:17, Thiago Macieira wrote: </pre> <blockquote type="cite"> <pre wrap="">On Friday, 13 July 2018 10:33:32 PDT L A Walsh wrote: </pre> <blockquote type="cite"> <pre wrap="">Why? If the TCP-PATH between systems is secure, how is dbus insecure? </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> The important assumption here is "usually". However, there are plenty of organizations/businesses that are able to deploy secured networks. </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> 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. <blockquote type="cite" cite="mid:8561045.yQd23Hn1zq@tjmaciei-mobl1"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> I don't know which great efforts you're speaking about are. I've never heard of anyone doing that.</pre> </blockquote> Probably my fault, this is what I meant (<a class="moz-txt-link-freetext" href="https://dbus.freedesktop.org/doc/dbus-tutorial.html">https://dbus.freedesktop.org/doc/dbus-tutorial.html</a>): <blockquote>" ...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..." </blockquote> <blockquote type="cite" cite="mid:8561045.yQd23Hn1zq@tjmaciei-mobl1"> <blockquote type="cite"> <pre wrap="">--- 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! </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> 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 <a class="moz-txt-link-rfc2396E" href="https://dbus.freedesktop.org/doc/dbus-specification.html"><https://dbus.freedesktop.org/doc/dbus-specification.html></a> 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] <a class="moz-txt-link-rfc2396E" href="https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga434e3fc7ee420fd30e2f05e57ff26b1d"><https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga434e3fc7ee420fd30e2f05e57ff26b1d></a> </body> </html>