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 <[email protected]>: > 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:[email protected]] > > > > Tomasz Świerczek > > Samsung R&D Institute Poland > > Samsung Electronics > > Office +48 22 377 95 59 > > Cell +48 503 135 021 > > [email protected] > > > > *From:* Zhang, Xu U [mailto:[email protected]] > *Sent:* Wednesday, October 29, 2014 8:04 AM > *To:* Tomasz Swierczek; [email protected] > *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:[email protected]] *On Behalf Of *Tomasz > Swierczek > *Sent:* Wednesday, October 29, 2014 12:38 AM > *To:* [email protected] > *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:[email protected]] > > > > Tomasz Świerczek > > Samsung R&D Institute Poland > > Samsung Electronics > > Office +48 22 377 95 59 > > Cell +48 503 135 021 > > [email protected] > > > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > >
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
