D-Bus daemon hits 100% CPU

[marcin at saepia.net]

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.
06.06.2016 9:08 PM "Simon McVittie" <simon.mcvittie at collabora.co.uk>
napisał(a):

> On 06/06/16 18:33, marcin at saepia.net 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. <http://www.collabora.com/>
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20160606/0b858d59/attachment.html>