[Dev] enforcing priviliges of web apps

Rafał Krypa r.krypa at samsung.com
Tue May 13 13:59:26 GMT 2014


On 2014-05-13 14:29, Patrick Ohly wrote:
> On Tue, 2014-05-13 at 11:13 +0000, Counihan, Tom wrote:
>> Sorry Baptiste – I probably need more coffee over here…..
>>
>>  
>>
>> So, is the browser process a singleton. Only one exists to service
>> many apps invoking W3C Interfaces?
>>
>> And for every application that invokes Tizen HTML5 APIs it has 2
>> dedicated process (extension & render).
>>
>>  
>>
>> Using an example, if I have 2 web applications:
>>
>> App 1:
>>
>>                 Invokes W3CFile API
>> http://www.w3.org/TR/2011/WD-FileAPI-20111020/
>>
>>                 Invokes: Tizen Bluetooth API;
>> https://developer.tizen.org/dev-guide/2.2.0/org.tizen.web.device.apireference/tizen/bluetooth.html
>>
>>  
>>
>> App 2:
>>
>>                 Invokes W3C Battery Status API
>> -http://www.w3.org/TR/2012/CR-battery-status-20120508
>>
>>                 Invokes NFC -
>> https://developer.tizen.org/dev-guide/2.2.0/org.tizen.web.device.apireference/tizen/nfc.html
>>
>>  
>>
>> I will end up with a total count of 1 browser process and 4 other
>> processes (2x extension & renderer) = 5 processes?
>>
>>  
>>
>> Is this correct?
> And to extend the question, which process will be the one talking to the
> rest of the system services?
>
> It has been said that the Crosswalk extension process will be used to
> implement Tizen specific APIs, but what about these W3C APIs? Will
> system requests required to implement those come from the single,
> one-per-user Crosswalk process that gets shared by different web apps?

If Crosswalk architecture is like that, with single per-user process accessing sensitive resources, then we have a problem.
In all recent discussions about application seucurity and policy enforcement it was assumed that different applications run in different processes. Furthermore, those processes were supposed to have different Smack labels to isolate them from another and to provide unforgeable application identity.
If Crosswalkis built on different principles, then IMHO it's a clash of subsystem architectures.
In Tizen 2 (at least in mobile profile)WRT was built with separate web processes per application. And we didn't trust WRT enough to let it enforce the policy, so Smack was used with per-app labels for enforcement.

Some quick thoughts about consequences of single, per-user web process:
- The web process, being single, will runwith a single Smack label for all applications.
- Locally created files will be also created with that Smack label, no separation of application data is possible at this level. Crosswalk will have to make sure that apps open only permitted files.
- Crosswalk will be the entity enforcing application policy. It can use Cynara as a policy source, but the actual enforcement will happen in the process running applications itself.
- If an application somehow manages to exploit Crosswalk and run arbitrary code in it's web process, it will get access to all sensitive resources of it's user. There is nothing that Smack could do to prevent that.
- I imagine that Crosswalk could permit two applications to interfere with each other, not necessarily in a desired way. I think of situations like in desktop browsers, when malicious web site can exploit the browser and get data from another web page, opened in second tab.

I am not an architect, It would be good to hear some opinions from appropriate decisive people.Maybe we just have to adapt freshly designed Cynara and it's surroundings to a requirement that we didn't know about so far.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140513/808a2421/attachment.html>


More information about the Dev mailing list