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

From: "Gix, Brian" <brian.gix@intel.com>
To: "michal.lowas-rzechonek@silvair.com" 
	<michal.lowas-rzechonek@silvair.com>
Cc: "johan.hedberg@gmail.com" <johan.hedberg@gmail.com>,
	"marcel@holtmann.org" <marcel@holtmann.org>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	"Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: [PATCH BlueZ 0/1] mesh: Add D-Bus Security for sensitive data
Date: Wed, 14 Aug 2019 21:02:14 +0000	[thread overview]
Message-ID: <FF0F331A-753C-4A3E-9EFD-E54BD0657DA8@intel.com> (raw)
In-Reply-To: <20190814205256.xkuqo4zqyl63erhc@kynes>

Hi Michał 

> On Aug 14, 2019, at 1:53 PM, "michal.lowas-rzechonek@silvair.com" <michal.lowas-rzechonek@silvair.com> wrote:
> 
> 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 don't think so.... If a token is leaked, and we offer *any* kind of mechanism to export keys, then any permissions that the App with legitimate access to the token has, is then conferred on *any* entity that obtains access to the token.  

The only way around this is to not allow any access, by any apps, to any exportable keys....   or to secure access to the token.

> 
> 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