> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Kis, Zoltan > Sent: Thursday, May 15, 2014 3:45 AM > To: Rafał Krypa > Cc: [email protected] > Subject: Re: [Dev] enforcing priviliges of web apps > > On Thu, May 15, 2014 at 1:27 PM, Rafał Krypa <[email protected]> > wrote: > > On 2014-05-15 11:59, Kis, Zoltan wrote: > > > > On Thu, May 15, 2014 at 11:55 AM, Zhang, Xu U <[email protected]> > 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 > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
