How about employing TLS for private DBus connections ?

[Simon McVittie]

On Wed, 10 Oct 2018 at 19:31:17 +0200, rony wrote:
> If it is o.k. with you and others in the D-Bus community I would try to reserve enough time over the
> Christmas vacation to attempt to add (experimental) TLS transport for evaluation.

Sorry, I can't promise to be able to review anything like this on any
particular timescale. Every hour I spend on reviewing this would be an
hour I don't spend on other D-Bus work.

I would recommend implementing this sort of thing as some sort of bridge
or tunnel, at least as a prototype, rather than immediately going for
something that would have to be included in libdbus and every other D-Bus
implementation in order to be used. That would bypass my maintainability
and review concerns by making it an independent project that is entirely
under your control; and if it has security vulnerabilities, those are
between you and your users, and don't have to involve the dbus maintainers.

For the server side, you could easily have a separate listening service
that responds to incoming connections by connecting to the dbus-daemon
on behalf of the incoming connection, and proxying traffic into it.
https://github.com/flatpak/xdg-dbus-proxy is a working example of a D-Bus
proxy, although this particular proxy listens on AF_UNIX sockets with no
additional security layer, rather than on TCP with TLS/PSK.

The unixexec transport is not currently applicable to Windows, but works
on Linux and should also work on *BSD and macOS, and this transport
makes it easy to prototype the client side of a bridge. For example,
here's a client address you can give to most D-Bus implementations
(at least libdbus, GDBus and sd-bus) to implement D-Bus-over-ssh:

    unixexec:path=ssh,argv1=smcv at reptile,argv2=systemd-stdio-bridge,argv3=--bus-path%3Dunix%3Apath%3D/tmp/123456789

That example is completely untested and quite possibly wrong, but that
address or something similar should result in a connection to the bus with
address unix:path=/tmp/123456789 on machine 'reptile', authenticated as
user 'smcv', assuming that 'reptile' has systemd and a ssh server.

systemd-stdio-bridge is a utility to connect its stdin and stdout to a
Unix socket. It's part of systemd, and is not portable, but reimplementing
it in a reasonably portable way shouldn't be particularly complicated;
the socat and netcat tools are similar. The busctl and machinectl tools
in systemd can both use systemd-stdio-bridge to access remote machines'
system buses, and can be consulted for sample code (in particular a
better set of ssh options).

If people want similar functionality for D-Bus on Windows, in principle
there would be nothing to stop someone from implementing a windowsexec:
or transport similar to unixexec:, but using a pair of pipes or TCP
bound to localhost for I/O between the helper subprocess and the D-Bus
client (the specification for unixexec: says it uses a fully-featured
Unix socket, and you can't do that on Windows). That *would* have to be
included in D-Bus client libraries, and the socket programming involved
would probably be tricky (because Windows is weird), but its scope is
a lot smaller than a TLS security model.

> The result should be that no one but those who have access to the same
> keystore/certificate would be able to communicate with each other (shared secret).

Please note that you seem to have already taken a design decision about
your security model here: this is one specific trust model, in which all
peers are equally trusted. If any malicious or compromised client leaks
the shared secret to a third party, then that third party can monitor
or impersonate every participant in the bus, including the message bus
itself. Perhaps this is OK for your use-case - I don't know - but it
won't be OK for every use-case. This trust-model design is the sort of
thing that has to be considered up-front when designing secure systems.

If your security model is that there is a shared secret and all peers
are equally trusted, please name your protocol accordingly. I think the
usual jargon term for this is a pre-shared key (PSK).

> - enough time to meet that challenge

A significant issue here is that time spent writing software is not the
only time that needs to go into it. Whenever I accept code into dbus,
someone - often me - needs to spend time responding to bug reports,
responding to security vulnerabilities, keeping it compiling on
newer systems, and so on, for years to come. TLS is complicated and
security-sensitive, and I don't think the dbus maintainers can afford
to increase the amount of maintenance dbus needs.

> - enough specific knowlege: not being a system programmer, let alone a Linux system programmer, I
> would benefit a lot, if you or other D-Bus developers could point me to the code that resolves the
> tcp address and sets everything up for a private D-Bus connection (and warnings, if you can
> foresee/speculate/know of potential problems).

Again, I'm sorry, but every hour I spend doing this is an hour I don't
spend doing things that I consider to be higher-priority, and I can't
justify that.

    smcv