How about employing TLS for private DBus connections ?

[rony]

Simon:

On 08.10.2018 12:15, Simon McVittie wrote:
> On Sat, 06 Oct 2018 at 15:27:42 -0700, L A Walsh wrote:
>> On 8/24/2018 3:43 AM, rony wrote:
>>> TLS would take care of encryption already.
>> ---
>>    While TLS may be needed over some networks, there are private or
>> home networks, where it wouldn't be needed.
>>
>>    Why can't the networks be graded as private, corporate or public
>> so rules can be applied as needed for the specific security situation?
>>
>>    This has worked for years on MS networks, so certainly it
>> should be good enough for linux.
> This is not really comparable, because Microsoft control every aspect
> of their operating system. The maintainers of dbus don't control every
> aspect of a single Linux distribution, let alone every implementation
> of Linux, *BSD, Darwin and all the other platforms the reference
> implementation of D-Bus is meant to work on.
>
> There are certainly implementations of networks marked as private,
> corporate or public on Linux systems - firewalld does that, for example -
> but not every user of dbus uses firewalld (and firewalld itself relies
> on D-Bus, so it would be a circular dependency if dbus relied on it).
>
> Microsoft presumably also pay multiple people to develop and maintain
> their IPC systems; I am not aware of any dbus contributor who works on
> it full-time. (I certainly don't.)
>
> If this is not acceptable to you, either don't use dbus, or help us.
> When we try to set a realistic scope for what we can support, telling us
> that we are not doing enough is not constructive.
>
>     smcv
that is very understandable!

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. The idea being to
allow an address "tls:host=...,port=...,keystore=..." instead of "tcp:host=...,port=...". To follow
the KISS principle the creation and deployment of the keystore/certificate that is needed on the
server and all client sides, would not be part of D-Bus, but part and responsibility of the
deployer. 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). As long as that
keystore/certificate is kept at a safe place on each machine, no one should be able to break in.

Having the ability to deploy private D-Bus client/server applications I really think this would be a
real great boon for application developers (and for D-Bus as well), if they became able to take
advantage of the D-Bus infrastructure to help them create simple client-server applications and be
able to mix and match Linux with Windows and MacOSX (addressing mostly small to medium businesses).

There are two specific problems that I might face: 
- enough time to meet that challenge (next possibilities would be February, Easter vacation and summer),
- 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).

Would that be something that would be interesting, helpful to the D-Bus community?

---rony