[Dev] enforcing priviliges of web apps (was: Re: New Tizen Bluetooth Framwork (NTB) wiki page)

Kis, Zoltan zoltan.kis at intel.com
Tue May 13 21:51:45 GMT 2014


On Tue, May 13, 2014 at 1:38 PM, Baptiste Durand <
baptiste.durand at open.eurogiciel.org> wrote:

> For each user we have only 1 Browser process
> And per User applications there are 2 process
> 1 render process (RP)
> 1 Extension Process (EP)
>
> So
> The browser process is in charge of W3C API
> The extension process is in charge of tizen API
> All W3C API for All Application for 1 user are managed by the Browser
> Process .
>
>
Yes, this is correct.
The browser runs the JS code implementing the API shim, which communicates
via JSON with the extension processes (at least for external extensions
such as Tizen extensions, since the internal extensions use the Chromium
internal IPC).
The extension processes are the ones implementing the platform specific
code, which maps the JS shim to the platform code (e.g. to DBUS, or
platform library interfaces) needed for API implementations.
The extensions may have multiple instances running (different pages =
different instances).
Now since Chromium uses libevent based mainloop, the extensions need to
launch a thread to run the glib mainloop in order to be able to talk with
DBUS. There may be one of these per extension/instance. This thread has to
have the permission to access DBUS.

>From here we have two options:
- either the extension 'inherits' the identity of the app, and eventually
fails in accessing DBUS, since the app doesn't have permission and the
system denies access
- or the extension can always access DBUS, and acts as a security manager:
check app id/manifest/web permissions, map it to platform permissions, and
enforce security policy.

In this model, native apps could also access the platform DBUS interfaces,
and security needs to be enforced e.g. in the DBUS daemon (by assumed
Cynara extensions to the dbus daemon).

An alternative model is what Dominig proposed. If I got it right, both
native apps and the Crosswalk extension processes would access the platform
only by using a library or libraries which expose the platform API in
question and implement an IPC (e.g. low latency zeromq) to the service
proxy process, where the following are done:
- app (native or web) identification
- mapping of web permissions to platform permissions
- enforcing the platform permissions according to the platform/device
security policy
- mapping the API calls to the platform API's: DBUS or other.

The main drawback here is the need to map every single platform
functionality to a new API, and then which API? The C API? OSP/C++? ASD
IDL->C++? An intermediate 'mother of all' API to which all previous are
mapped? Looks very idealistic/irrealistic to me, given the limited time and
resources we have. Also, the optimal process model of the service proxy is
not clear.

My question is, would the first model work, i.e.
- xwalk extensions are part of the system and enforce web API permissions
(or alternatively are transparent, but can still access DBUS)
- DBUS interfaces (e.g. BlueZ, ofono, connman, etc) are secured by
extensions to the DBUS daemon, so that native apps could use DBUS if they
have declared the mapped permissions and the policy allows it
- other cases could go through the service proxy or proxies.

Best regards,
Zoltan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140514/5e61677e/attachment.html>


More information about the Dev mailing list