On Mon, 2014-11-17 at 18:20 +0000, Xu, Martin wrote: > Patrick: > > > > I've argued that it is the latter (see also > > https://bugs.tizen.org/jira/browse/TC-1411) while the NTB developers claim > > that the less secure access control in NTB is good enough for 3.0. > > > Please let me know > Where you can find that "that NTB developers claim > that the less secure access control in NTB is good enough for 3.0."??? > > Stop misleading people here, please!!!!
I see how my summary can be misleading. My apologies for that. I didn't mean to imply that you consider the current implementation good enough for 3.0 final. Quite the opposite, we both agree that the real work still needs to be done. However, we disagree about the state of phase 1. You insist that it has been fully implemented according to the requirements, and I doubt that. Most likely we simply have a different understanding of the requirement. But perhaps there's also a misunderstanding about the implementation. Show me how you prevent malicious users from accessing a paired phone that they are not meant to have access to and I will accept that my understanding of the current implementation is wrong and phase 1 has indeed been implemented according to my understanding of it. > Let me repeat the Multi-user status one more time, I do not want to > repeat again. !!!! > > When we start to work on multi-user support, Dominique show us 4 > phrase Multi-user support, after our evaluation, we found that we can > only support phrase 1 just from NTB One more time: what you define as phase 1 is not how I define it. Either that, or we have a complete disconnect on how NTB is going to get integrated into Tizen. > Base on the concept that Tizen applications must go through CAPI to > get Bluetooth servicer. That concept is wrong both technically (there are ways of doing Bluetooth without CAPI) and conceptually (CAPI as it stands today is not suitable to be the only Bluetooth API (see PBAP), and perhaps never will be (see the meta discussion about wrapping system services in additional APIs)). > So after negotiate with Dominique, we will just implement phrase 1 > before merge NTB into Tizen-3.0. In my opinion, you shouldn't bother with phase 1 in NTB at all because it is not secure and the real, secure solution in Bluez will supersede it later. If I may offer an analogy: how useful is a door against burglars if you cannot lock it? Considering all that, I don't consider implementation of phase 1 an acceptance criteria for NTB in Tizen 3.0. My question to Dominig was an attempt to get his opinion about that, because as I remember it, he was the one who made it a requirement. > After that we will work with BlueZ upstream to find the proper > solution. That's the right way forward. > I have answered your question many times. Tizen Bluetooth application > can't have supper right to do everything directly to BlueZ or other > system resource. It must go through CAPI to get system resource, and > under some security control. That is what I understand of the _basic_ > Tizen concept. That is what I learned during past years working on > Tizen. If you think that is not right, please tell me what is the > right concept? You missed one thing: libraries cannot enforce security or access control. Every daemon which provides services requiring privileges and which is accessible by an untrusted application has to implement that itself. NTB is primarily a library on top of the Bluez daemons, so security must be implemented in Bluez (either upstream or in Tizen). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
