[Dev] enforcing priviliges of web apps

Kis, Zoltan zoltan.kis at intel.com
Thu May 15 10:44:56 GMT 2014


On Thu, May 15, 2014 at 1:27 PM, Rafał Krypa <r.krypa at samsung.com> wrote:
> On 2014-05-15 11:59, Kis, Zoltan wrote:
>
> 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
> a).
>
>
> Minor note: B1b would not be faster than B1a, it would only add overhead.
> Cynara will provide a library (libcynara-client) for access checks and it
> will already implement caching. On cache hit in libcynara-client it won't
> contact the Cynara daemon, but just return cached value. Cache flushing
> should also be transparent for Cynara users.

Very nice, thanks! That leaves either A, B1(a), or B2 as options, the
main issue being to patch dbus-daemon for supporting Cynara and hence
allowing direct access from native apps and crosswalk extensions. What
is your take on this?

Thanks,
Zoltan


More information about the Dev mailing list