[Dev] enforcing priviliges of web apps

José Bollo jose.bollo at open.eurogiciel.org
Tue May 13 14:09:51 GMT 2014


On mar, 2014-05-13 at 15:59 +0200, Rafał Krypa wrote:
> 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 Crosswalk is 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 run with 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 agree with you. There is a problem. Is was thinking that the W3C API
was handled at the renderer process level. Having it common to all apps
is a problem for the reasons you written.

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

+1

Best regards
José
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev




More information about the Dev mailing list