Date:   Wed, 10 Apr 2019 20:26:45 +0200
From:   Michal Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
To:     "Stotland, Inga" <inga.stotland@intel.com>
Cc:     "Gix, Brian" <brian.gix@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "marcel@holtmann.org" <marcel@holtmann.org>,
        "luiz.dentz@gmail.com" <luiz.dentz@gmail.com>,
        "johan.hedberg@gmail.com" <johan.hedberg@gmail.com>
Subject: Re: [PATCH BlueZ 1/1] mesh: Add APIs for Provisioner and Config
 Client
Message-ID: <20190410182645.r7lprmpz3jfggill@kynes>
Mail-Followup-To: "Stotland, Inga" <inga.stotland@intel.com>,
        "Gix, Brian" <brian.gix@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "marcel@holtmann.org" <marcel@holtmann.org>,
        "luiz.dentz@gmail.com" <luiz.dentz@gmail.com>,
        "johan.hedberg@gmail.com" <johan.hedberg@gmail.com>
References: <20190322225754.27039-1-brian.gix@intel.com>
 <20190322225754.27039-2-brian.gix@intel.com>
 <20190401104213.vpqhgw55leg6olza@scytale>
 <DEBB0CAA2616974FAE35E4B560B9A4376CAE27AA@ORSMSX103.amr.corp.intel.com>
 <20190405190304.swhyog5zefvq37e2@kynes>
 <D6866572D7A1DB48A0D22000C21836C76CFD7997@ORSMSX103.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D6866572D7A1DB48A0D22000C21836C76CFD7997@ORSMSX103.amr.corp.intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi,

On 04/05, Stotland, Inga wrote:
> > Imagine an existing network provisioned by someone else, (...)
> > We would like to add a Linux-based device to that network. (...)
> > To achieve that, we need some kind of API that allows provisioning
> > meshd locally, ideally via D-Bus.
>
> To me, this scenario seems to me more like "import the node" rather
> than "provision the device".

Yes, indeed. Having an API to import a complete node into the daemon
would be enough. But note that such an import would need to contain, and
*all* the keys, device key included.

> We could do that with either a new Import(dict cofiguration) method,
> where configuration is a dictionary that contains all the preset
> values (netkeys, uuid, unicast, etc). This method is different from
> Create() since the netkeys are coming from the "outside".

Yes, that would do, but there seem to be some objections to passing keys
over DBus.

> The current approach is to keep all the netkeys and appkeys within the
> daemon without ever exposing them to an application.

Yeah, I know. I just don't think it's practical to assume this, because
of the use cases mentioned earlier in this thread. I strongly feel there
is a need for a centralized database, handled outside of the daemon,
ideally on a some kind of internet server.

> Alternatively, If a node has been created and configured by a third
> party then adding it to the existing meshd management could be
> achieved by transcribing its configuration into a meshd internal
> storage format (which is in json readable form and could be
> potentially exposed as a schema).

That's true, but this would also mean that the storage format becomes an
API.

I don't think this is a good idea, I'd rather allow the daemon to modify
storage format freely (with a proper migration from older versions, of
course). Especially considering that while JSON works for now, I think
in a long run node data should be stored in some kind of transactional
database.

> > Moreover, since the Attach() token already travels through the bus (...)
> Just having the token is not enough: there are some checking
> mechanisms (and I believe they need to be extended) to check the
> validity of the attaching application.

As far as I can see, these checks mostly concern composition data
(elements/models in particular), and this can be easily queried. Mesh
daemon doesn't seem to use any additional secrets besides the token.

So from what I gather, the daemon already depends on the bus being
secure, and I don't see any practical difference between exchange of
tokens and exchange of keys.

> > > Most of your recommendation directly affect the security of the Keys, 
> > > and whether they get passed via D-Bus...  And this is something that I 
> > > would *not* do without the OK from Marcel Holtmann (...)
> > Could you please point me to the relevant thread? I know I'm late to
> > he party and would very much like to catch up, as much as I can.
> This was a verbal discussion I believe.

Oh... Could someone (Brian? Marcel?) please summarize the main points
then? It's hard to argue about arguments I cannot possibly know :(

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