[Dev] Crosswalk single process model and Privilege enforcement side effect.

José Bollo jose.bollo at open.eurogiciel.org
Thu Dec 11 14:35:02 GMT 2014

Le jeudi 11 décembre 2014 à 12:23 +0100, Dominig ar Foll a écrit :
> Hello,
> following the annoucement by the Crosswalk team abandon of the shared
> process model in favour of the single process model (which actually
> create two processes), I want to raise a few remarks and opened
> questions linked to that change.
> A) Loss of trusted status.
> ---------------------------------
> In the share process model, the Browser process and Renderer process
> were running with system privileges and was protected by a specific
> Smacks label. No Apps could fake the Browser process and for that raison
> the system was able to trust it what was allowing us to locate the
> enforcement of some App privileges at that level (at least on the paper,
> as in the real world, the implementation proved to be serious challenge,
> forcing Crosswalk team to abandon that model).
> In the new model the Browser Process will run with the same AppID than
> the Apps itself.
> It means that the system will not be able to differentiate both reliably
> and so, we will not be able to trust the Browser process any more for
> capability enforcement.
> With this change, the requirement for implementing the support of Native
> App privileges enforcement becomes urgent.

> B) Browser Process and App are both untrusted
> ---------------------------------------------------------------
> We need to treat Crosswalk running an HTML5 App as a native App and
> enforce the privilege externally what will be done by a bundle of tools
> which includes (smack label and Smack rules, Cynara, special groups).


There is also a model where crosswalk is also the launcher, meaning that
is starting with some rights that it quickly drops. This would maybe
become necessarily because the process has two lives: the transient
setting-up age and the application running age. Launching a process (the
renderer process) obviously requires a privilege that the launched
application would not have.

> C) My questions
> -----------------------
> 1) The security model for native App was agreed during the Aug14
> Security workshop in Vannes. Where is located the associated
> documentation. In particular the list of privileges applicable to native
> Apps.

Tomasz Swierczek sent the proposed core list for tizen 3.x [1] & [2].

The new API 2.3 is listing separately the native [3] and web [4]
privileges (for mobile). These list only have minor differences.

> 2) Do we have a 1:1 mapping between HTML5 and Native privileges. If not
> (what I expect) where is that mapping.

There is not an exact mapping in tizen 2.3. In tizen 3.0 I dont know.
And there is IIRC no documentation of mapping.

> 3) What is the exact list of privileges enforcement which were
> "subcontracted" to the browser process in the share process model.

We received from Sakari the list:

Here are the 5 APIs BP is protecting via manifesto. We need to re-plan
the implementation now with the new process model:

0752. The following special privileges are supported:

     *   Geolocation API: http://tizen.org/privilege/location
     *   Web Notifications API: http://tizen.org/privilege/notification
     *   Getusermedia API: http://tizen.org/privilege/mediacapture
     *   FullScreen API: http://tizen.org/privilege/fullscreen
     *   Storage Use API (quota exceeding WebDatabase, IndexedDB, and
FileSystem capacity):http://tizen.org/privilege/unlimitedstorage

> 4) What is the time table for implementation of the Native App privilege
> enforcement.
> Regards

Best regards
José Bollo

[1] https://wiki.tizen.org/wiki/Security:Tizen_3.0_Core_Privileges
[2] https://lists.tizen.org/pipermail/dev/2014-October/004749.html

More information about the Dev mailing list