Linux-Bluetooth Archive on lore.kernel.org
 help / color / Atom feed
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
Date: Wed, 14 Aug 2019 22:52:56 +0200
Message-ID: <20190814205256.xkuqo4zqyl63erhc@kynes> (raw)
In-Reply-To: <dbffabec9a869204b4de1aab645fd727949e655e.camel@intel.com>

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

  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14  1:43 Brian Gix
2019-08-14  1:43 ` [PATCH BlueZ 1/1] doc: Add Pub/Private ECC shared secret to obscure " Brian Gix
2019-08-14  8:14   ` Vallaster Stefan
2019-08-14  7:52 ` [PATCH BlueZ 0/1] mesh: Add D-Bus Security for " Michał Lowas-Rzechonek
2019-08-14 16:41   ` Gix, Brian
2019-08-14 20:52     ` michal.lowas-rzechonek [this message]
2019-08-14 21:02       ` Gix, Brian
2019-08-14 21:20         ` michal.lowas-rzechonek

Reply instructions:

You may reply publically 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=20190814205256.xkuqo4zqyl63erhc@kynes \
    --to=michal.lowas-rzechonek@silvair.com \
    --cc=brian.gix@intel.com \
    --cc=inga.stotland@intel.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /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

Linux-Bluetooth Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-bluetooth/0 linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ https://lore.kernel.org/linux-bluetooth \
		linux-bluetooth@vger.kernel.org linux-bluetooth@archiver.kernel.org
	public-inbox-index linux-bluetooth


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-bluetooth


AGPL code for this site: git clone https://public-inbox.org/ public-inbox