On Tue, 2014-06-17 at 13:34 +0300, Kis, Zoltan wrote: > On Tue, Jun 17, 2014 at 12:34 PM, Patrick Ohly <[email protected]> wrote: > > On Tue, 2014-06-17 at 09:19 +0000, Zhang, Xu U wrote: > >> > >> > -----Original Message----- > >> > From: Patrick Ohly [mailto:[email protected]] > >> > Sent: Tuesday, June 17, 2014 5:13 PM > >> > To: Zhang, Xu U > >> > Cc: Tomasz Swierczek; Schaufler, Casey; Kis, Zoltan; > >> > [email protected]; > >> > He, Xinchao; [email protected] > >> > Subject: Re: [Dev] The SAPI proposal > >> > > >> > On Tue, 2014-06-17 at 08:59 +0000, Zhang, Xu U wrote: > >> > > The general flow for Tizen API case is as below: > >> > > (1) When Tizen device JS API such as Bluetooth.read() is called, render > >> > process will send IPC to extension process firstly. > >> > > (2) When extension process receives the message, extension process > >> > > will call SAPI > >> > > >> > ... or some other system services. I suggest to describe the extension > >> > process > >> > as "calling the system" instead of "calling SAPI", because for the > >> > security > >> > architecture of Crosswalk it is irrelevant how the system exposes > >> > services, as > >> > long as it does securely. > >> > > >> > It is relevant for actually writing the extension code, of course. Right > >> > now, > >> > extensions cannot call SAPI (does not exist yet) while they can call > >> > existing > >> > services. This takes us from architecture considerations into the realm > >> > of the > >> > more practical "how do we actually get work done"; not sure whether we > >> > want > >> > to go there. > >> > > >> [Zhang Xu ] Yes, you are right. For Tizen crosswalk extension, > >> currently extension process call system APIs directly. So we need add > >> a check before calling system APIs to make sure extension process has > >> the permission to access. > > > > No, I think it is better to treat the extension process as an untrusted > > part of the app (because then we can load untrusted native extensions > > into it) and rely on the system to enforce privilege checks. > > > > Yes, this way, but the details are still important. In this context, > for me system API's mean DBUS (with enforcement hopefully on > dbus-daemon level, making it directly usable from native apps and > extensions rather than wrapping all DBUS services in SAPI) + any other > protected service (where the service calls Cynara) + "legacy" API's > via SAPI + system calls (file access, shared mem, etc). This would be > minimally intrusive.
Yes, we need to keep discussing and working on this. That's why a statement like "Crosswalk's extension process calls SAPI" is premature and potentially misleading (if understand and/or meant as "... and nothing else"). > > If we can't achieve that second part, then making the extension process > > a trusted component and relying on Crosswalk to do all checking is plan > > B. This puts an additional burden on the Crosswalk team, though, and is > > only an intermediate step to the final system architecture. > > In the past I was wondering why we don't do this, but the fact that > extensions can be guest code/deployed as/with apps, eliminates this. Agreed, I just didn't bother repeating that argument. However, can third-party extensions be deployed already today? This did not become clear to me from Xu's answer to José's question. If this is not possible already, we could delay implementing the necessary support and then the extension process could be treated as trusted. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
