Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 14 Aug 2019 22:52:56 +0200
From:   "michal.lowas-rzechonek@silvair.com" 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.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
Message-ID: <20190814205256.xkuqo4zqyl63erhc@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "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>
References: <20190814014357.32453-1-brian.gix@intel.com>
 <20190814075200.j3jmxpto7kszjjkp@mlowasrzechonek2133>
 <dbffabec9a869204b4de1aab645fd727949e655e.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <dbffabec9a869204b4de1aab645fd727949e655e.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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