Return-Path: Date: Fri, 15 Feb 2013 10:57:26 +0200 From: Johan Hedberg To: Bastien Nocera Cc: Antonio Ospite , linux-bluetooth@vger.kernel.org Subject: Re: [PATCH BlueZ 0/2] Add device_set_trusted() Message-ID: <20130215085726.GA10022@x220> References: <1359908071-15024-1-git-send-email-ospite@studenti.unina.it> <20130215083611.GA5750@x220> <1360917653.2283.39.camel@novo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1360917653.2283.39.camel@novo> Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Bastien, On Fri, Feb 15, 2013, Bastien Nocera wrote: > > This patch set makes me a bit uneasy since setting a device as trusted > > is a security sensitive operation. My initial reaction is that this > > should only be done through explicit user interaction, i.e. through the > > D-Bus interface. > > How is using D-Bus interface "user interaction"? It's not any more user > interaction than doing it this way, which avoid going out through the > public interface for something we are setting up ourselves. Typically you'd get a pop-up dialog on the next connect attempt from this device "accept connection from foo?" with a check-box or similar to elect setting it as trusted. Alternatively the stuff that this plugin does upon initial device setup could cause a similar pop-up dialog to be presented to the user. > > I'm also worried that plugins will start misusing this > > API once it's available. > > I think that it's completely fair for plugins that *do* set up devices > to call this function. That's what the plugin is all about. Seeing as > devices should be marked as trusted to be usable, I see no reason that > this shouldn't be done automatically. How does the plugin that this API is primarily targeted for setup the device? Does it do it through some physical connection like USB? In such a case it's probably fine to skip the user interaction part since if you've got physical access to the device there are much severe security issues to consider. Johan