Hi Jose!
Back from TDC, I found this email thread and I have few questions, especially after discussions we had during the conference on the same topic. 1. What are the intentions of SAPI? I understand, that for some privileges/APIs, if there is *no service* right now, *and* such API/privilege is not heavily speed-dependent, we can introduce a daemon and in such cases, SAPI fits fine, without the need to modify original library/code that invokes proper actions on system-level resources. But are we going - as I understood from wiki page - to introduce this as mandatory architecture item that will separate apps from *all* services? Am I right? 2. How about resources that need to be accessed directly? For some reason (I don't want to discuss them right now - camera would be an example I guess) some resources may need to be accessed without a service proxy. Of course, in such case user-space access control is not really possible, because we can't trust the application's process. In one of previous Cynara thread (subject: [Dev] Access control design for user applications) we proposed and agreed with Casey to do this layer of access control with additional GIDs assigned to applications. Is this idea/use case missing on your picture intentionally (dropping such possibility? There is no arrow from apps to resources on the bottom) or is it just a minor thing not presented there? 3. How about performance? The image on wiki page suggest we're going to have at least 2 IPC mechanisms - if an app calls, for example, BT service APIs (taken from image on wiki page, "The SAPI proposal"), it needs to communicate with SAPI and SAPI needs to communicate with Core BT Service. Additionally, if Core BT Service would be using DBus, it would mean that we have even more IPC & context switches there (since we have to talk to DBus daemon too). This is quite a lot in terms of context switches and data copying from one process to another. Now, while I understand we may want to ease the switch to Cynara this way *and* [point 1], I wonder what are the actions we will take in SAPI to minimize this performance penalty? Have you tried this approach on a reference device? Some numbers? I belive we should test this approach first. 4. General privileges question - Cynara has to ask about privileges on behalf of applications. Which privileges are you planning to use? SAPI layer would need to be aware of all privileges exposed by underlying Core-level services. I guess we'd want to re-design the privilege model for 3.0 and beyond, but do you have any plans on this? Best Regards, Tomasz Świerczek Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 95 59 Cell +48 503 135 021 [email protected] -----Original Message----- From: Dev [mailto:[email protected]] On Behalf Of José Bollo Sent: Friday, May 23, 2014 2:34 PM To: [email protected] Subject: [Dev] The SAPI proposal Hi all, I just finished the wiki page that describes SAPI, the Secure CAPI, proposal: https://wiki.tizen.org/wiki/Security/SAPI SAPI, the secure CAPI, is an implementation of the CAPI over IPC. The clients call the service SAPI through an API implementing CAPI. The service SAPI checks the privileges using Cynara. Some of us are thinking that it is a good proposal because: - Applications don't need to be rewritten (OSP ones) - It standardize the model - Most of the work to produce SAPI can be automatized But it is subject to debate. Please share any information, data and arguments using wiki pages: https://wiki.tizen.org/wiki/Security/SAPI https://wiki.tizen.org/wiki/Talk:Security/Overview https://wiki.tizen.org/wiki/Security/Overview Best regards José _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
