linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Stotland, Inga" <inga.stotland@intel.com>
To: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	"Gix, Brian" <brian.gix@intel.com>
Cc: "michal.lowas-rzechonek@silvair.com" 
	<michal.lowas-rzechonek@silvair.com>
Subject: Re: [PATCH BlueZ v3 3/3] mesh: Fix Key Ring permissions for local nodes
Date: Fri, 27 Sep 2019 02:50:25 +0000	[thread overview]
Message-ID: <112b44e9e00c909a1d98997df1eeed0c2151eb0b.camel@intel.com> (raw)
In-Reply-To: <0a384749e155689d7981a443059d6cb5a6522f75.camel@intel.com>

[-- Attachment #1: Type: text/plain, Size: 4479 bytes --]

Hi Brian,

On Thu, 2019-09-26 at 23:27 +0000, Gix, Brian wrote:
> On Thu, 2019-09-26 at 20:41 +0000, Stotland, Inga wrote:
> > Hi Brian,
> > 
> > On Thu, 2019-09-26 at 11:14 -0700, Brian Gix wrote:
> > > We do *not* automatically create populated key rings for imported
> > > or
> > > joined nodes,
> > 
> > Why not for Import()? Since both the DevKey and NetKey are in the
> > possesion of the node...
> 
> There are two (known) use cases for Import()
> 
> 1. Node previously existed on a different physical piece of hardware,
> and is being migrated to this daemon.
> 
> 2. Node was newly provisioned Out-Of-Band, and this is the net result
> of the provisioning.
> 
> In *neither* case is it a given that the Node should be able to
> provision another node (the effect of adding
> the Net Key to the key ring). In neither case is it a given that the
> Node should be able to modify it's own
> Config Server states (the effect of adding it's Device Key to the key
> ring).
> 
> However, if it *is* the case that one or more of these operations
> should be available to the Node, the
> Application that performed the Import may call the ImportSubnet()
> and/or the ImportRemoteNode() methods. In
> actuality, if this was the intent (particularily on a Node being
> migrated) a key-ring of some sort should have
> existed on the other physical piece of hardware.
> 
> 
> The point of this larger patch-set is to no longer assume that every
> Node has the ability to use it's own
> network keys to provision other nodes, or use it's own Device Key to
> change it's own Config Server states.
> 
> Yes, that can still happen (as it can with non BlueZ nodes) but it
> should be by a deliberate mechanism, not as
> a "time saving default".
> 
> 
> 

Sounds good. Could you please add this description to the commit
message?

> > > but we also do not *forbid* any node from adding a key
> > > in it's possesion to the local key ring.
> > > ---
> > >  mesh/manager.c |  5 -----
> > >  mesh/node.c    | 15 ---------------
> > >  2 files changed, 20 deletions(-)
> > > 
> > > diff --git a/mesh/manager.c b/mesh/manager.c
> > > index 501ec10fe..633597659 100644
> > > --- a/mesh/manager.c
> > > +++ b/mesh/manager.c
> > > @@ -282,7 +282,6 @@ static struct l_dbus_message
> > > *import_node_call(struct l_dbus *dbus,
> > >  void *user_data)
> > >  {
> > >  struct mesh_node *node = user_data;
> > > -struct mesh_net *net = node_get_net(node);
> > >  struct l_dbus_message_iter iter_key;
> > >  uint16_t primary;
> > >  uint8_t num_ele;
> > > @@ -298,10 +297,6 @@ static struct l_dbus_message
> > > *import_node_call(struct l_dbus *dbus,
> > >  return dbus_error(msg, MESH_ERROR_INVALID_ARGS,
> > >  "Bad device
> > > key");
> > > 
> > > -if (mesh_net_is_local_address(net, primary, num_ele))
> > > -return dbus_error(msg, MESH_ERROR_INVALID_ARGS,
> > > -"Cannot overwrite local device
> > > key");
> > > -
> > >  if (!keyring_put_remote_dev_key(node, primary, num_ele, key))
> > >  return dbus_error(msg, MESH_ERROR_FAILED, NULL);
> > > 
> > > diff --git a/mesh/node.c b/mesh/node.c
> > > index 833377e99..af45a6130 100644
> > > --- a/mesh/node.c
> > > +++ b/mesh/node.c
> > > @@ -1681,7 +1681,6 @@ static void get_managed_objects_cb(struct
> > > l_dbus_message *msg, void *user_data)
> > > 
> > >  } else if (req->type == REQUEST_TYPE_IMPORT) {
> > >  struct node_import *import = req->import;
> > > -struct keyring_net_key net_key;
> > > 
> > >  if (!create_node_config(node, node->uuid))
> > >  goto fail;
> > > @@ -1692,23 +1691,9 @@ static void get_managed_objects_cb(struct
> > > l_dbus_message *msg, void *user_data)
> > >  import->net_idx, import-
> > > > net_key))
> > >  goto fail;
> > > 
> > > -memcpy(net_key.old_key, import->net_key, 16);
> > > -net_key.net_idx = import->net_idx;
> > > -if (import->flags.kr)
> > > -net_key.phase = KEY_REFRESH_PHASE_TWO;
> > > -else
> > > -net_key.phase = KEY_REFRESH_PHASE_NONE;
> > > -
> > >  /* Initialize directory for storing keyring info */
> > >  init_storage_dir(node);
> > > 
> > > -if (!keyring_put_remote_dev_key(node, import->unicast,
> > > -num_ele, import-
> > > > dev_key))
> > > -goto fail;
> > > -
> > > -if (!keyring_put_net_key(node, import->net_idx,
> > > &net_key))
> > > -goto fail;
> > > -
> > >  } else {
> > >  /* Callback for create node request */
> > >  struct keyring_net_key net_key;

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]

  reply	other threads:[~2019-09-27  2:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 18:14 [PATCH BlueZ v3 0/3] mesh: Fix Remote/Local dev key usage Brian Gix
2019-09-26 18:14 ` [PATCH BlueZ v3 1/3] mesh: Add remote boolean to DevKey transactions Brian Gix
2019-09-26 18:14 ` [PATCH BlueZ v3 2/3] mesh: Explicit Remote/Local Device key usage Brian Gix
2019-09-26 20:40   ` Stotland, Inga
2019-09-26 18:14 ` [PATCH BlueZ v3 3/3] mesh: Fix Key Ring permissions for local nodes Brian Gix
2019-09-26 20:41   ` Stotland, Inga
2019-09-26 23:27     ` Gix, Brian
2019-09-27  2:50       ` Stotland, Inga [this message]
2019-09-26 20:40 ` [PATCH BlueZ v3 0/3] mesh: Fix Remote/Local dev key usage Stotland, Inga
2019-10-01 18:07 ` Gix, Brian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=112b44e9e00c909a1d98997df1eeed0c2151eb0b.camel@intel.com \
    --to=inga.stotland@intel.com \
    --cc=brian.gix@intel.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=michal.lowas-rzechonek@silvair.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).