How to ensure DBUS is broken (in clusters and bus-connected NUMA machines)

[Linda A. Walsh]

Colin Walters wrote:
> http://illmatics.com/Remote%20Car%20Hacking.pdf
>
> 1) Exposing the bus over TCP.  I'd recommend having debugging sessions go over ssh.
> 1a) Exposing the bus over TCP to all interfaces, including an interface for the public internet
>   
^^ agreed, mostly, but allowance for honeypot usage?
> 2) Using the ANONYMOUS mechanism  (related to #1)
> 3) Not using PolicyKit or other authorization mechanism
> 4) Having a method that executes arbitrary code mixed in with normal methods
>   
re: #4 -- imagine a compute engine that requires expensive authentication
and/or link encryption over a cluster internal bus  -- it would be
a design killer.


As far as the basic assumption on this -- consider 'dbus' used on a closed
network for high-speed (>=10Gb) cluster nodes to communicate w/each 
other  --

You really DON'T want encryption in such cases, as no encryption layers
that I know that can even be used on a 1Gb connection without a notice-able
impact in speed and latency.

The "required encryption", vs. Hi-speed requirements have long been a point
of contention between openssh developers and Hi-speed communications needed
in high-speed computing -- requiring hi-speed computing labs/researchers to
develop and deploy 3rd party patches for each new release of openssh.

I first noticed slowdowns on 1Gb networks in file transfer and remote-GUI
sessions, at least 6-8 years ago when 1Gb became affordable for home
usage, and noted use of ARC4 (on its way to be deprecated, unfortunately)
noticeably sped up session-setup and reduced latency.  With 10Gb links
ssh can easily cause 75% or greater bandwidth loss vs. unencrypted
channels. 

Dbus needs to have some idea of when it is only traversing an internal
network vs. when it is exposed to an external internet.

I.e. for inter-node transport in a cluster, I'd hate to see forced 
encryption
over Dbus or relying on expensive-out-of-process authentications (polkit)
that would kill latency times.