[Dev] Tizen 3.0 Core privilege list - bluetooth case

Bumjin Im bj.im at samsung.com
Thu Oct 30 08:18:59 GMT 2014


Hi,

Yes, bluetooth privilege covers all the previous OSP/WRT bluetooth related privileges.
For Core(Native) privileges, we managed to couple each privilege with real resource, in the bluetooth case, the bt service. We also tried to minimize # of privileges.

Bumjin

------- Original Message -------
Sender : Corentin Lecouvey<corentin.lecouvey at open.eurogiciel.org>
Date : 2014-10-30 00:39 (GMT+09:00)
Title : [Dev] Tizen 3.0 Core privilege list - bluetooth case

Hi Tomasz, 


I see in the new privileges list that bluetooth privileges were reduced to :

- http://tizen.org/privilege/bluetooth
- http://tizen.org/privilege/bluetooth.admin


Previously there were one privilege associated to one bluetooth profile.
- http://tizen.org/privilege/bluetooth.spp
- http://tizen.org/privilege/bluetooth.hdp

- ...


I understand that an application having new bluetooth privileges can connect to any bluetooth profiles.
Is it the intended behavior ? 
Did I misunderstand something ?


Thanks and regards,
Corentin






2014-10-29 10:42 GMT+01:00 Tomasz Swierczek <t.swierczek at samsung.com>:

Hi Xu!

The differences between Tizen 2.2.1 and 3.0 are intentional. In Tizen 3.0 we would like to limit number of privileges and keep them more resource-centric. The list I’ve published was created by Mr Bumjin Im (Thanks Bumjin for that very good piece of work!) based on Tizen 2.X privilege list. If there was a compliance specification, then we’d need to stick to that. However, in Tizen 3.0 currently we don’t have anything like this. Moreover, in Tizen 3.0 you can observe that many application frameworks are available for the application developer and some of them may have their own, already defined sets of privileges  - Crosswalk with W3C-related privileges is a good example, another is when you install a Tizen 2.2.1 application ? obviously, it will have different set of privileges. That “different set of privileges” will have to be matched during installation to subset of privileges that underlying OS supports. From what I know, this is what Crosswalk already does on Android ? when building/installing crosswalk application package it translates its own privileges to Android ones (according to what we’ve found, for example here: https://crosswalk-project.org/documentation/manifest/permissions.html).

Let me give you an example in Tizen 2.X (the pdf document that you’ve linked) ? there are, for example, privileges:

For web:             http://tizen.org/privilege/location
For native:          http://tizen.org/privilege/geolocationpermission.read

One contains (or equals) to the other. Tizen 2.2.1 had defined two and only two application frameworks ? native (OSP) and Web (previous Web Runtime) so that made perfect sense. 

Now, in Tizen 3.0 we will have many application frameworks (there is EFL, Xwalk, Qt, … - we aim to provide embedded, mobile, common, IVI, TV and other profiles) that are ontop of the operating system ? and that OS serves certain functionalities to all of them, typically implementing some services. Each of these services is tied to some resource ? so it makes more sense to provide one privilege for resource rather than make different granularity for each of application types. For example, It would require an additional amount of (I think unnecessary) work for the geolocation service to check for one privilege OR the other based on application type. In Tizen 2.X it didn’t matter because application-level privileges were mapped directly to sets of Smack rules that gave access to services and resources, so each service didn’t have to care about OSP, WRT, etc. privileges that gave an application access to it. Now in Tizen 3.0 when we want to implement a user-space access control based on privileges, each service needs to have the privilege defined ? because it needs to actively ask/check Cynara if an application has access to it.

However, if (some) application framework requires different granularity and simple translation (as Crosswalk does in Android example) is not possible, then it is the application framework’s duty to properly check for the exact permission level it aims to distinguish (this is also what Crosswalk does in Browser Process for some of the W3C specific APIs like geolocation, from what I know).

As for missing privileges ? as I wrote on the wiki page and in the email, the list is not strictly closed. Its rather a 1st attempt to document what underlying system will recognize and what we will use. I think that privileges you’ve mentioned probably make sense ? can you please say a little more exactly what permissions app will gain when having these privileges?

@Bumjin ? do you think we should add these privileges to the list?

Best Regards,


Tomasz ?wierczek
Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 95 59
Cell +48 503 135 021
t.swierczek at samsung.com

From: Zhang, Xu U [mailto:xu.u.zhang at intel.com] 
Sent: Wednesday, October 29, 2014 8:04 AM
To: Tomasz Swierczek; dev at lists.tizen.org
Subject: RE: [Dev] Tizen 3.0 Core privilege list

Tomasz,

Thanks for summarize Tizen 3.0 core privilege list.  I noticed there are some different between the list https://wiki.tizen.org/wiki/Security:Tizen_3.0_Core_Privileges and compliance spec. (Because there is no compliance spec for Tizen 3.0, I refer Tizen 2.2.1 spec https://source.tizen.org/sites/default/files/page/tizen-2.2.1-compliance-specification-for-mobile-profile-v1.0.pdf).
In Tizen compliance, the privileges are composed of 3 parts: 
1.       W3C/HTML5 API related Privileges
2.       Supplementary API related Privileges
3.       Tizen Web Device API related Privileges
I can’t find below privileges from core list:
l  http://tizen.org/privilege/mediacapture (W3C/HTML5 API related Privileges)
l  http://tizen.org/privilege/unlimitedstorage (W3C/HTML5 API related Privileges)
l  http://tizen.org/privilege/fullscreen (Supplementary API related Privileges)

What do you think of above privileges? Are they missed or skipped in Tizen 3.0?

Thanks
Zhang Xu
From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Tomasz Swierczek
Sent: Wednesday, October 29, 2014 12:38 AM
To: dev at lists.tizen.org
Subject: [Dev] Tizen 3.0 Core privilege list

Hi All,

As part of our work on privilege-based access control model with Cynara in Tizen 3.0, we’ve gathered Tizen 3.0 Core privileges in one place: https://wiki.tizen.org/wiki/Security:Tizen_3.0_Core_Privileges

On last F2F security workshop in Vannes Intel and Samsung teams decided that this is the privileges set we will start our work with when implementing security checks. These privileges will be used to check application’s access to any of Tizen OS services/functionalities. This is the list of privileges that Security Manager will expect to get from application installers and this is the set of privileges that Cynara will be asked for.

Aside from the list itself, I’ve added comments on what exactly these privileges mean to the system and how/by who should be used. The list is not strictly closed, it is rather an effort to document what we will use later (within a month I guess) when configuring Tizen access control mechanisms.

Best Regards,



Tomasz ?wierczek
Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 95 59
Cell +48 503 135 021
t.swierczek at samsung.com


_______________________________________________
Dev mailing list
Dev at lists.tizen.org
https://lists.tizen.org/listinfo/dev


More information about the Dev mailing list