[Dev] enforcing priviliges of web apps

Poussa, Sakari sakari.poussa at intel.com
Thu May 22 11:11:24 GMT 2014

On 5/22/14, 12:34, "Patrick Ohly" <patrick.ohly at intel.com> wrote:

>Just to clarify: the EP will run with the Smack label of the app that it
>was created for?


>> So we have two cases. 1) Tizen Device APIs et al which are in the EP and
>> 2) W3C APIs which are in RP+BP, BP being the relevant part here.
>> The plan is to add the API permission checks in the following way:
>> Case 1: Tizen Device APIs et al
>> Since the EP is not sandboxed, it can talk use the libcynara directly or
>> talk to Service API layer, which then talks to cynara. The EP has all
>> information in hand to do so including the smack label, user id and
>> application id.
>EP <-> "some (D-Bus) system service" depends on the EP having the app's
>Smack label.

OK. That would not be a problem. See above.

>Again, for clarity's sake: we agree that the BP not only can talk to
>Cynara, it also must and will do it? Because once the BP contacts a
>system service, that service no longer knows what app it is servicing
>and can only check that the BP itself is allowed to use the service.

Yes, for the APIs that need permission checks. Currently, we are planning
of supporting the same as Tizen 2.x which includes geolocation,
getUserMedia(camera), web notifications, full screen and database access
(indexed and websql).

BP is the trusted module which must do the right thing. Otherwise security
is compromised.

>Have you already started to look into actually adding the libcynara
>calls? In the libcynara API discussion I was reprimanded for speculating
>whether the current synchronous API is good enough for Crosswalk; it
>would be good if some Crosswalk developer responsible for calling
>libcynara in the BP could look at the API and confirm that it is

No - Not yet. All these plans are fresh as today. But we will very soon.

>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.

More information about the Dev mailing list