Hi all, 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 user. Is bluetooth/bluez engine creating specific objects/interfaces for the communication between end-user-client and service BT, once the device is paired? 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 via DBUS. From a security point of view, it is a hole because how to avoid clients to try guessing? Best regards José Bollo _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
