How about employing <anything> (now: TLS, later?)

[Simon McVittie]

On Sun, 15 Jul 2018 at 13:16:02 -0700, L A Walsh wrote:
>    Falling back to definition -- what about co-processing systems where
> they are, together, considered 1 system.

One of the major problems with a clustered setup is that you have to
make assumptions about identity, security, and addressing resources. The
assumptions that D-Bus traditionally made were the same as the assumptions
under which NFSv3 was traditionally deployed:

* identity: numeric UIDs are shared (uid 1000 on each machine is the same)
* security: only authorized machines have access to the LAN, and all
  authorized machines are equally trusted to enforce identity (if one
  machine says I am uid 1000, then I can be uid 1000 on all machines)
* addressing resources: filesystem paths (or at least those in /home)
  are common to all the machines involved

However, these assumptions are fragile. In particular, if any unauthorized
machine (including a phone, games console or smart-fridge) can join the
LAN, then the security assumption is broken. As soon as one of those
assumptions is broken, the setup as a whole is wrong; and we can't detect
whether those assumptions are broken, so we can't even warn about that.

>    Fortunately, at least some of those with secure networks aren't really
> demanding all the wizz-bangs that would be needed in a hostile environment.

That's fine up to a point, but dbus-daemon can't tell the difference
between your secure network, my local coffee shop's hostile environment,
and Jeep's expensive recall. Experience demonstrates that, unfortunately,
anything that is possible will tend to be treated as fully supported,
and not making insecure configurations harder to achieve seems like an
abdication of responsibility.

You'll notice that current versions of dbus-daemon can still do TCP,
and can still do ANONYMOUS, for the benefit of people with the same
setup/point of view as you: if we had been more aggressive about removing
functionality, this would have vanished a few years ago. However, don't
count on this remaining true next time there's a security incident that
it would have prevented, because at some point removing "sharp edges" is
going to become more important than preserving traditional functionality.
I don't want D-Bus to get a reputation for being insecure, even if that
reputation is really the fault of people who misconfigure it; if it gets
a bad enough reputation that developers stop using it, then you will not
be able to use it to make existing software communicate between machines
in any case, and everyone loses, including you.

One possibility for the future of D-Bus on clusters would be to run the
dbus-daemon on one machine, listening on an AF_UNIX socket, and run a
separate bridge that listens on TCP (possibly with TLS or similar) and
proxies connections to that dbus-daemon. Another possibility would be
to proxy connections via ssh, like systemd's
`busctl -H othermachine --system` does. If clustered D-Bus is important to
you, I would encourage you to pursue one of those routes: that would make
it explicit that the security assumptions and security model belong to the
proxy, which (unlike the dbus-daemon) should only be deployed on trusted
networks.

The dbus-proxy/ directory in flatpak is an example of an implementation
of proxying D-Bus connections (it uses AF_UNIX, but could be adapted).

    smcv