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@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND