[Dev] Tizen 3.0 Core privilege list - bluetooth case

Corentin Lecouvey corentin.lecouvey at open.eurogiciel.org
Wed Oct 29 15:39:13 GMT 2014


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,
>
> [image: 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-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,
>
>
>
> [image: 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
>
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20141029/f6c93341/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/f6c93341/attachment-0001.png>


More information about the Dev mailing list