[Dev] Crosswalk single process model and Privilege enforcement side effect.
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 :
> 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
Tomasz Swierczek sent the proposed core list for tizen 3.x  & .
The new API 2.3 is listing separately the native  and web 
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
> 4) What is the time table for implementation of the Native App privilege
More information about the Dev