How not to use dbus (in cars or anywhere else)

[Simon McVittie]

On 25/08/15 17:47, Thiago Macieira wrote:
> On Tuesday 25 August 2015 15:23:13 Simon McVittie wrote:
>> However, removing support for TCP would break one of the use-cases for
>> which D-Bus-over-TCP was designed: sharing a bus on a trusted LAN,
>> alongside a NFS home directory, DBUS_COOKIE_SHA1 (proving you can access
>> $HOME) for authentication, and probably shared X11
> 
> Is that the same as the Windows mechanism?

You'd think so, but actually no.

DBUS_COOKIE_SHA1 over the tcp: transport authenticates by proving you
can access a file ("cookie") in your (presumably shared) home directory.
It's also the fallback over unix:, if your OS has Unix sockets, but does
not have a credentials-passing mechanism supported by D-Bus for EXTERNAL
auth. In practice I don't know of any specific OSs where that's needed,
since most Unixes have getpeereid() or equivalent, and since 1.9.x the
default config for the system and session buses explicitly disables
non-EXTERNAL auth on non-Windows.

The nonce-tcp: transport has an additional layer of authentication on
top of that, which if I understand correctly, is *also* about proving
you can access a file in your (presumably shared) home directory, but
done as part of the transport instead of during the SASL negotiation. I
don't know why DBUS_COOKIE_SHA1 wasn't considered to be sufficient, and
there doesn't seem to be any rationale given in the git history.

The two primary use-cases of D-Bus (the system bus and the session bus
on vaguely Unixish systems) should be fine with the unix: transport and
EXTERNAL authentication on any reasonable platform. For instance, I
don't think sd-bus actually supports anything except EXTERNAL.

> Anyway, this is relying on NFS security. If NFS is secure for you, who are we 
> to disagree?

People who would rather not be run over by a hacked Jeep, or otherwise
damaged by whatever embedded device does D-Bus wrong next? :-P

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>