On gio, 2014-06-12 at 11:15 +0200, Tomasz Swierczek wrote: > Hi Jose! Hi Tomasz,
> 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. (reminder https://wiki.tizen.org/wiki/Security/SAPI and https://wiki.tizen.org/wiki/Talk:Security/Overview) You are mainly right: reusing existing code. There are also some other intents. - To let upstream middlewares untouched, unpatched (connman, bluez, ...). - To manage the critical resource/service acquiring or sharing between users and applications. This is very important for the multiuser case inside the framework. - It is convenient to use a good C API (as opposite to use UDS or DBUS). Thus some C API will be needed to not access low level API. - (subjective) The core API is well designed and has a kind of good fitting with the definition of privileges. > 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? Making it mandatory (as libc) is would be a dream (not a nightmare) but isn't pragmatic for many rationals. > 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. We dont have all the answers. This is a good question. For critical timing resources, the API would be mainly used for signalisation and the data would be streamed by . For the direct accesses, data would go aside: using a file descriptor received from UDS, using a service (like gstreamer), or filesystem (with namespaces or not). Noboby wants to check any frame of a video stream with Cynara. The camera API is designed to use gstreamer (such use case is an interesting security topic!). In the multi user environment of IVI, we are expecting to have more than one camera and to apply user policy when acquiring it. > 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) https://lists.tizen.org/pipermail/dev/2014-April/002490.html > 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? It's due to an oversight. Thank you for recalling it. > 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. The page https://wiki.tizen.org/wiki/Talk:Security/Overview is made for the discussion on this subject. SAPI is built on top of a FAST communication system. Many more fast than DBUS. About BT, some work is currently done for making a BT framework (on DBUS) that will call BLUEZ (on DBUS). Thus SAPI could integrate directly the BT framework. So architectural design does matter in the discussion. > 4. General privileges question - Cynara has to ask about > privileges on behalf of applications. Which privileges > are you planning to use? https://wiki.tizen.org/wiki/Security/Overview#The_privileges > SAPI layer would need to be aware > of all privileges exposed by underlying Core-level services. Yes it is the case. I didn't start to work on it currently. Some of the API verbs will be checked (not all, for example, verbs creating handles for ressources will need to be checked but if the resource is created, checks will be optional). As Patrick Ohly wrote, there is also the question of the "session-id". > I guess we'd want to re-design the privilege model for 3.0 > and beyond, but do you have any plans on this? We aren't working on any re-design. I'm still investigating SAPI. We are just trying to implement the current design. Best regards José > > > 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
