How about employing <anything> (now: TLS, later?)

[L A Walsh]

Thiago Macieira wrote:
> Fair enough.
> Please understand that opening an unauthenticated and unencrypted 
> TCP port for either well-known D-Bus bus, you're basically 
> saying the entire network is part of the same system and ALL 
> processes running in it, in any node connected to it, have the same 
> privilege rights.
>
> If you're comfortable with that, go right ahead.
>   
----
    Absolutely.  There are various examples of this:

1) a cluster.
2) a 'co-processing' machine -- this close to what I have.  My desktop
has no direct external access.  It doesn't have any data on it.  It is 
missing
many things needed for normal function.  They are on a second dedicated
machine that provides disk space, network proxies, email, etc.  In my case,
the two machines are literally connected with 1 10Gb ethernet wire and
no intervening switches.  No encryption, is needed between them, with
the user database being 90% on the server -- I login with a password on
the workstation.  After that most processes communicate over open TCP or 
UDP.

3) similar to the above would be using a VPN or forwarded network via SSH
to secure a connection to a solo instance on a server -- either a virtual
machine or a machine separating users with MAC (fluke/SELinux, SMAC) (which
extends down into the network layer w/labeling like CIPSO labeling).  If
you've never been on such a machine -- the network appears *dead*, if no
other machines with your security label are on the network.  It can't be
overridden by the user w/o giving them privs to install a new kernel, but
machines talking CIPSO over the wire won't acknowledge or see non-compatible
network packets.  TCP/UDP/ICMP packets are all labeled and provide complete
data separation from other-labeled and non-labeled traffic.
>> Turning to another aspect of D-Bus that seems to have been overlooked in
>> many discussions: D-Bus can also be used to create private D-Bus servers,
>> which is a *very* easy, straight forward process. If a network is secured
>> in an organization, then one can safely take advantage of it for
>> server-client applications within an entire network!
>>     
>
> Correct. If you're comfortable with unauthenticated and unencrypted 
> connections, you can use this. As you said, the security must come from the 
> lower layer.
>   
----
    Right...see above.  There are many clients with secured networks
>   
>> In effect, I speculate that the D-Bus developers and maintainers do not
>> realize the potential this would allow for, otherwise support for TLS would
>> have been created and made available for the D-Bus reference
>> implementation.
>>     
>
> We do, we just don't consider it the main focus or effort. That is 
> why TLS not implemented. That's simply not what D-Bus is 
> designed for.
>   
---
    Although...it is always good practice and a sign of good SW design to
to leave hooks for later parameterization, where one sees the opportunity.
Though most such hooks cannot be seen in advance, sufficiently
modular code can be more easily split apart to allow for such.

> If you want that, I recommend using the "D-Tube" functionality inside 
> libdbus-1 that allows you to get a DBusMessage from a byte stream and also 
> write a byte stream from a DBusMessage. How you transmit and receive those 
> bytes is then up to you. But even that functionality is limited, as we've 
> never written the code to initialise a DBusConnection (much less a bus 
> connection) without the handshake protocol, for which there is no "D-Tube"
>
>   
>> To stress this point a little bit more: if it was possible to use private
>> D-Bus servers over TLS (e.g. [5], [6], [7]), then D-Bus would be a dynamite
>> infrastructure for creating powerful client-server applications in an easy,
>> straight-forward and fast manner for all kinds of client-server application
>> needs over the entire web, no matter in which language and on which
>> operating systems the servers or clients execute! (It would probably put
>> SOAP and REST into the shade in many respects.)
>>     
>
> That's called AllJoyn. It has been done and is about a decade old.
>   
---
    If that's the case, why is effort being spent on DBUS?  To what
goal that AllJoyn wouldn't support?  Personally, I try to grab working
code from other places to start with -- and either use it directly, or
try to make it compatible to make it easily extensible by others.  Not
always possible, but those who reinvent the wheel and make it incompatible
with the original would seem to be wasting their talent.  I.e. if
smart enough to invent some replacement, think about how the concept(s)
could be advanced if they could work on new stuff on building on the old
instead of reinventing the old.