Linux-Bluetooth Archive on lore.kernel.org
 help / color / Atom feed
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
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

  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
2019-08-14 21:02       ` Gix, Brian [this message]
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=FF0F331A-753C-4A3E-9EFD-E54BD0657DA8@intel.com \
    --to=brian.gix@intel.com \
    --cc=inga.stotland@intel.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.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

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