<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-text-plain" wrap="true" style="font-family:
-moz-fixed; font-size: 14px;" lang="x-unicode">
<pre wrap="">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] <a class="moz-txt-link-rfc2396E" href="http://wi.wu.ac.at/rgf/rexx/orx22/201112-DBus4ooRexx-article.pdf"><http://wi.wu.ac.at/rgf/rexx/orx22/201112-DBus4ooRexx-article.pdf></a>, p. 19-21.
On 15.10.2018 12:55, Simon McVittie wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">On Wed, 10 Oct 2018 at 19:31:17 +0200, rony wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
<a class="moz-txt-link-freetext" href="https://github.com/flatpak/xdg-dbus-proxy">https://github.com/flatpak/xdg-dbus-proxy</a> 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@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 <b class="moz-txt-star"><span class="moz-txt-tag">*</span>would<span class="moz-txt-tag">*</span></b> 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.
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">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).
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">- enough time to meet that challenge
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">- 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).
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
</div>
</body>
</html>