[Dev] Finished the multi-user BT phase1 source code and the related test report
jose.bollo at open.eurogiciel.org
Mon Oct 20 10:13:43 GMT 2014
On dom, 2014-10-19 at 09:00 +0200, Dominig ar Foll (Intel OTC) wrote:
> Le 17/10/2014 09:17, Zheng, Wu a écrit :
> > Hi Patrick,
> >> I suspect you were assuming that all processes can only do Bluetooth via your framework. If yes, then you need to
> >> A. ensure that all Bluetooth users in Tizen do that,
> >> B. and then (and only then!) ensure that all other ways of doing
> >> Bluetooth are prohibited.
> > It should be A and B.
> > And Doming has some suggestion and we will do it too.
> > " the easiest implementation is to run only one NTB daemon with privilege and to get the user to pass their request via the daemon."
> > " we run NTB as a special user (e.g. bluetooth), then we can limit any transport creation access via BlueZ control to that privilege user."
> Yes, it should be A and B.
> We have multiple option to activate these restriction from Smack to D
> Bus policy.
Such restriction are already made in bluetooth.conf. It is working
without use of Smack or Cyanara. The policy is made on users and groups.
>From reading that file, it appears that the group 'bt_use' is the group
to be in to get control. But I'm not expert of the topic...
> I would rather see the daemon running with as little privilege as possible.
Yes, IMHO, it should be a system user of name 'bluetooth' and of group
'bluetooth' (instead of 'bt_use').
The NTB daemon and the bluetooth daemon could be running as 'bluetooth',
allowing them to communicate through DBUS with a policy based on the
Is bluetooth/bluez engine creating specific objects/interfaces for the
communication between end-user-client and service BT, once the device is
If yes, the "address" of that object have to be open to end users in the
current design where end-user-client exchange directly with the service
>From a security point of view, it is a hole because how to avoid clients
to try guessing?
More information about the Dev