Re: [PATCH BlueZ 0/1] mesh: Add D-Bus Security for sensitive data

["michal.lowas-rzechonek@silvair.com" <michal.lowas-rzechonek@silvair.com>]

Hi Brian,

On 08/14, Gix, Brian wrote:
> I would like Marcel to weigh in on this since the security of exposing
> keys via D-Bus was initially a concern raised by him.
Ok.

> Also, we may be able to leave it in the hands of the Application that
> owns the node.  It could be as simple as the Application decides to
> secure the D-Bus channel (for only itself) by performing the Public
> Key Exchange.
For the record - I understand the hesitation to "trust" the applications
to correctly handle security and I don't mean to dispute this. I
understand that once keys are exfiltrated from a network, all hell
might break loose.

Leaking meshd's tokens does not lead to that situation - at worst, one
could impersonate a single node.

I also agree that key export is sensitive and accesing these should
require some kind of authorization scheme.

> If the Application does *not* request a Public Key from the Daemon,
> and/or does not supply a Public Key during Attach/Join/Import, then
> the APIs work the same as they do today (albeit with extra ignored
> parameter(s)).
This sounds complex.

Stefan raised a point about app and net keys being visible in plaintext
when application attempts to configure a node (both local and remote).

This might lead to adding encryption to mesh payloads exchanged between
the daemon and the application. Such a thing would IMO defeat the whole
idea of mesh stack implemented as a system service - it would be easier
to implement this behaviour as a library and do all the crypto on the
application side.

> An app that knows it is opperating in a secure environment can then
> trust the system to provide all needed security, but if for instance,
> some sort of hybrid D-Bus that has an insecure link in the chain, thwe
> App can add the Public Key exchange and encrypt/decrypt as needed.
As far as I know, there are only a handful of D-Bus daemon
implementations out there, and I don't think that any of them is
inherently insecure. Sure, there might be bugs and vulnerabilities, but
I am not aware of any implementation that includes an "insecure link".

Please keep in mind that D-Bus is confined within a single machine -
yes, there is a TCP transport, but virtually all setups have this turned
off, and IIRC freedeskop.org explicitly states that this feature should
not be used in a production environment.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND