Re: D-Bus daemon hits 100% CPU

On 06/06/16 18:33, [email protected] 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus