How about employing TLS for private DBus connections ?

[Simon McVittie]

On Mon, 08 Oct 2018 at 06:04:39 -0700, L A Walsh wrote:
>    Actually, I'm more concerned about you doing too much -- to remove the
> ability to have an open architecture that can allow remote connections
> with the security of 'rsh'.  The network that is used on is over a
> closed circuit. with only 2 devices on it (2 computers).

I do have some sympathy for this, and that's why I still haven't followed
through on my 2015 proposal[0] to remove or restrict non-local TCP:
removing existing functionality is not a decision to be taken lightly.

However, this reasoning only works as long as non-local
TCP support isn't giving D-Bus a bad name. If incidents like
https://www.bbc.co.uk/news/technology-33650491 result in developers
considering D-Bus to be insecure - whether it's true or not is irrelevant,
it's the perception that matters here! - then they will stop using D-Bus
for communication between their programs, and you will *still* lose the
ability to have their programs communicate over D-Bus within your cluster,
without the dbus maintainers having done anything. I don't want that to
happen any more than you do.

(I will also not be able to continue to put my time into maintaining
D-Bus and dbus if general-purpose "free desktop" Linux and *BSD systems
stop using them, because their usefulness to my employer is entirely
to do with D-Bus being a de facto standard for the system and session
buses on GNU/Linux.)

In a sense, adding wording to the spec about the TCP transport being
insecure works in your favour: next time there's an avoidable security
flaw as a result of some embedded vendor using unauthenticated D-Bus,
the more strongly we have discouraged it, the more credibly we can say
it was the embedded vendor's fault, not D-Bus' fault.

If you use a bridge (see my mail to rony elsewhere in this thread)
rather than relying on the D-Bus implementation itself having code for
non-local TCP, then possible future restriction or removal of non-local
TCP wouldn't affect you. I would recommend this.

I would also recommend using a ssh tunnel, even though in your case it's
unnecessary, unless you have performance numbers that say the network link
is enough of a bottleneck that the cost of encryption and authentication
is significant.

(In general we don't have enough realistic benchmarks and performance
numbers for D-Bus, so if you do have those performance numbers I'd be
interested to see them.)

> with the security of 'rsh'

If the public perception of D-Bus ever gets as bad as the public
perception of rsh[1][2], then that would be a very bad sign for its
future.

Yes, rsh can be used securely, under very special circumstances, and
you have arranged for those circumstances to happen on your systems;
but that doesn't make rsh popular, or a good idea to recommend in general.

    smcv

[0] https://lists.freedesktop.org/archives/dbus/2015-August/016763.html
[1] http://www.informit.com/articles/article.aspx?p=169465
[2] https://www.beyondsecurity.com/scan_pentest_network_vulnerabilities_rsh_detection
both from the first page of Google hits for "rsh security"