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."
Best Regards
Zheng Wu
-----Original Message-----
From: Patrick Ohly [mailto:[email protected]]
Sent: Friday, October 17, 2014 2:36 PM
To: Zheng, Wu
Cc: [email protected]; Jia, Pei P; Liu, Bingwei; Linkmeyer, Mark J
Subject: Re: [Dev] Finished the multi-user BT phase1 source code and the
related test report
[Bluetooth Framework New Generation and implications for Tizen this year]
On Thu, 2014-10-16 at 07:33 +0000, Zheng, Wu wrote:
> I have tested the source code. It matches the requirements of
> multi-user BT phase1.
>
> Please check the following BT test results.
>
> a. UserA and UserB is in IVI. DeviceA is the remote BT devices.
>
> 1. UserA paired with DeviceA.
> UserA can audio connect with DeviceA.
> UserA can hid connect with DeviceA.
> UserA can socket connect with DeviceA.
> UserA can send files to DeviceA.
> ......
>
> 2. At the same time, userB can't audio connect with DeviceA.
> UserB can't hid connect with DeviceA.
> UserB can't socket connect with DeviceA.
> UserB can't send files to DeviceA.
> ......
How do you prevent that user B bypasses your daemon and talks to the kernel
and/or system bluetooth daemon directly, and thus does these things that it is
not allowed?
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.
For A, work with the Tizen managers (if you need help from other teams) or
propose patches yourself (otherwise). For B, look at the security mechanisms in
Tizen.
If you do B without A, then you'll break working features. This is likely to
not please Tizen IVI with its planned release end of this year, so I am copying
Mark Linkmeyer.
--
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.
--- Begin Message ---
Zhang
if we 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.
Once that we can limit the creation of the transport pipe, then OBEX (or
other transport) can be use by the user.
The challenge is to limit access to the BlueZ signaling (pairing,
connection, ...), there is no real need to control the transport much
after that. Just need to "only" give the access right to a given App for
a given user) what can be done with a smack rule at the creation of the
connection.
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
Le 23/09/2014 12:40, Zheng, Wu a écrit :
> Hi Dominig,
>
> Thanks for your suggestions.
>
> Just OBEXD run on each user mode, NTB need to manage and control the related
> features of OBEXD(such as pbap, opp and so on).
> It is why NTB need to run on each user mode.
>
> NTB run on each user mode(such as userA and userB) with privilege, can NTB
> stop ogue user to access the lower level directly?
> Thanks.
>
> Some suggestions?
>
> Best Regards
> Zheng Wu
>
> -----Original Message-----
> From: Dev [mailto:[email protected]] On Behalf Of Dominig ar Foll
> (Intel OTC)
> Sent: Tuesday, September 23, 2014 6:29 PM
> To: [email protected]
> Subject: Re: [Dev] FW: FW: Tizen 3 services: use case for multi user
>
> Hello,
>
> the easiest implementation is to run only one NTB deamon with privilege and
> to get the user to pass their request via the daemon.
> With that model we can stop rogue user to access the lower level directly and
> NTB can implement the multiuser policy.
>
> Dominig ar Foll
> Senior Software Architect
> Open Source Technology Centre
> Intel SSG
>
> Le 23/09/2014 12:01, Patrick Ohly a écrit :
>> On Tue, 2014-09-23 at 09:53 +0000, Zheng, Wu wrote:
>>>> What prevents a rogue user process from ignoring NTB and using obexd
>>>> and/or the system's Bluetooth support directly (i.e. replicate obexd
>>>> inside the process itself)?
>>> It need to be analyzed cases by cases.
>> If you don't know, then check it first. If it turns out to be
>> impossible, then it might not be worth implementing access control in
>> NTB at all because it will have to be done again elsewhere (kernel?).
>>
>> Even if it turns out to be feasible, then it cannot be turned on
>> without first ensuring that all uses of Bluetooth go through NTB.
>>
> _______________________________________________
> Dev mailing list
> [email protected]
> https://lists.tizen.org/listinfo/dev
--- End Message ---
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
