[Dev] enforcing priviliges of web apps

Kis, Zoltan zoltan.kis at intel.com
Thu May 15 09:59:28 GMT 2014

On Thu, May 15, 2014 at 11:55 AM, Zhang, Xu U <xu.u.zhang at intel.com> wrote:
> [Zhang Xu ] Patrick, Bai (who has left Intel) and I have designed crosswalk API permission control. The doc is here https://docs.google.com/a/intel.com/document/d/137u_gxmNaIFwVzaCkCFBJyveIdZxuAydWOkMI8oWgD0/edit

I think that's a good/flexible design. App process invokes an API
function. The renderer process (RP) sends a message to the extension
process (EP), which checks whether permission is granted. On need the
browser process (BP) pops up a user dialog.

> and the implementation is done. I am informed that all web device APIs implementation should use Cynara’s service API directly. So the design will be dropped from web runtime side.
> I will implement crosswalk runtime security issues.

Here we have options.

A. Security (service) proxy is the only enforcement point. Dominig's proposal.
In this case the EP is totally transparent and inherits the app identity.
We need to solve how the browser process will know to pop up a user
dialog for permissions.
Also, all API's that are accessed by the web runtime need to be
exposed by the service proxy, which is a huge work with huge delay.

B. There may be multiple enforcement points (EP, dbus-daemon,
service-proxy). This allows direct DBUS access from apps, and in the
rest works like in A. Sub-options:
1.) EP is also enforcement point, and part of the system. Then, EP
checks if access is allowed, either by
a) asking Cynara, or
b) EP caches policy data from Cynara (with an update/sync mechanism
for that data) and makes a local decision, which is much faster than
2.) EP is not an enforcement point (only dbus-daemon and service-proxy
are). Then it works like in A, but EP would have direct access to DBUS
API's, making the transition much easier, and the work much lighter
than in A.

In either case, you can reuse the upper part of your design.
Currently only A. is a proposal, although B. is forming up to be a
proposal, too.
The issue is still debated in the architecture forum, but IMO it would
be enough if security experts would analyze both, publish it here, and
select one of them (A, B1a, B1b, or B2). So far the analysis part is
not clear (except for A). Personally, I would be fine with either B1b
or B2.

Best regards,

More information about the Dev mailing list