[Dev] Tizen 3.0 Core privilege list

Tomasz Swierczek t.swierczek at samsung.com
Wed Oct 29 09:42:49 GMT 2014


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,

cid:44YDXKW4QKNM at namo.co.kr

 

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-spe
cification-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,

 

cid:44YDXKW4QKNM at namo.co.kr

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20141029/2582eb18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2228 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20141029/2582eb18/attachment-0001.png>


More information about the Dev mailing list