When I write so far I mean the development environment. In production it's not going to be open to the world, just listening on localhost so I have to open ssh tunnel first, and in both sides of the tunnel I operate on local port that was opened by ssh. If someone hacks my ssh I am screwed anyway, isn't that secure enough? I can't really rely on stuff like shared home directory as I need my app to conform to 12 factor. I also need full bus, one of the reason why I use DBus is ability to call ListNames M. <div class="gmail_quote">06.06.2016 9:08 PM "Simon McVittie" <<a href="mailto:simon.mcvittie@collabora.co.uk">simon.mcvittie@collabora.co.uk</a>> napisał(a): <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/06/16 18:33, <a href="mailto:marcin@saepia.net">marcin@saepia.net</a> wrote: > I use custom session bus. Really minimal config, just > tcp, anonymous auth (so far) and default limits It is precisely this sort of setup that led to the Jeep hack. Seriously, please don't. Even if you absolutely need to use TCP due to language/runtime limitations, please don't expose it beyond localhost and don't use ANONYMOUS authentication. The DBUS_COOKIE_SHA1 authentication mechanism uses a shared home directory to prove that a user has the uid they claim to have. It is also entirely possible to proxy D-Bus connections from the reliable transport of your choice to AF_UNIX (and have the proxy authenticate with the bus), at which point sole responsibility for providing security clearly falls on the proxy. If your situation does not closely resemble one of the two well-known buses (session/user or system) then you might be better off running a DBusServer instead of a dbus-daemon, and using the message-passing layer of D-Bus without the message bus layer. I don't intend to remove ANONYMOUS or non-local TCP support from that, only from dbus-daemon. > I understand that Ford hack must have been an issue but I think > disabling ability to listen beyond localhost is a bad idea, as in some > environments it is exactly what is wanted. Redis server by default is > also open and the Web hasn't collapsed yet. I can understand this point of view, and I'm somewhat sympathetic to it, but every time someone sets D-Bus up like this and an attacker takes advantage of it, it harms D-Bus' reputation. I don't want prospective open source platform builders to think "D-Bus, wasn't that how they got into the Jeep platform?" (and maybe the equivalent for whatever you're doing here), and use it as a reason to avoid D-Bus in situations where it is in fact the right tool for the job. D-Bus's two primary use cases are the session/user bus for communication within a desktop or desktop-like user session (AF_UNIX + EXTERNAL, uid required to match the server) and the system bus for communication between users and/or system services (AF_UNIX + EXTERNAL, uid looked up in the system authentication database). It's useful in analogous roles on servers and embedded devices - great, please use it like that too. It is sometimes good for other situations, which we should encourage, but only when they are not causing a problem for the primary use cases. The fact that you have to do specific reconfiguration to open up a bus to TCP, and then again to enable ANONYMOUS authentication, is clearly not enough to make everyone suitably wary about it - if developers had thought about why they were jumping through those hoops and reconsidered whether it was appropriate to do so, a multi-billion dollar product recall could have been avoided. -- Simon McVittie Collabora Ltd. <<a href="http://www.collabora.com/" rel="noreferrer" target="_blank">http://www.collabora.com/</a>> _______________________________________________ dbus mailing list <a href="mailto:dbus@lists.freedesktop.org">dbus@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/dbus" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/dbus</a> </blockquote></div>