[Dev] enforcing priviliges of web apps

Schaufler, Casey casey.schaufler at intel.com
Thu May 15 14:38:59 GMT 2014


> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Kis, Zoltan
> Sent: Thursday, May 15, 2014 3:45 AM
> To: Rafał Krypa
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] enforcing priviliges of web apps
> 
> 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_gxmNaIFwVzaCkCF
> BJy
> > veIdZxuAydWOkMI8oWgD0/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?

It is already possible to configure dbus to control access based
on Smack labels. There should be no need to change dbus. There
will need to be dbus configuration written for those services.



> Thanks,
> Zoltan
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev


More information about the Dev mailing list