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. > 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. Best regards, Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
