How about employing TLS for private DBus connections ?

[rony]

Thank you for your information, Simon!

The idea would be to follow the KISS principle and have a TLS transport support on all operating
systems.

Hence the idea of a PKS serving as a nonce, making it also clear that the security is dependent on
having that deployed in a secure manner; if an organizational security breach occurs there it is
clear that that is not the fault of D-Bus.

Your hints, explanations about the unixexec protocol were very interesting, clearly it (with all
services, configurations) need to be available on all systems. If it was possible to solve the
problem by that mean for all systems in a consistent way, this would solve the problem, to allow one
to have private D-Bus applications deployed on Linux, MacOSX and Windows interact with each other,
no matter on which of these systems the clients and the server reside.

As a TCP transport is available already, my initial idea was to find the respective relevant modules
in D-Bus and adapt them to allow a TLS transport using (maybe only initially) PKS as the shared
secret on all systems. (If using a private D-Bus was possible on Linux, MacOSX and Windows, then it
would become possible for me to have interested business administration students create secured
client/server applications for small to medium sized businesses, which with the ooRexx
programming/scripting language D-bus bindings would be quite easy [1].)

---rony

[1] <http://wi.wu.ac.at/rgf/rexx/orx22/201112-DBus4ooRexx-article.pdf>, p. 19-21.


On 15.10.2018 12:55, Simon McVittie wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20181018/cc7de4e6/attachment.html>