On Thu, Jun 12, 2014 at 5:50 PM, José Bollo <[email protected]> wrote: > 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.
Could you list specific examples? For audio [/video/network/cpu] policy we already have Murphy. > > - 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. How do you handle asynchronous idioms, e.g. [DBUS] signals/listeners, the existence/appearance of [DBUS] interfaces/objects with the C API, etc? Depending on external factors (provider, location etc), services may present different sets of interfaces. If you implement a general purpose mechanism for this, you get close to libdbus. > > - (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). This signaling will be done for each system API call? Then you need to wrap every system API call in the SAPI, and performance hits will be huge. Or is there a notion of a "session" when an app gets a session-token for accessing the resources permitted by the manifest at a specific point (installation, launch)? > > 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. Where are these 'user policies' checked, and could you list some use cases? It seems overlapping with media/device resource policy what Murphy is doing. IMO sapi-daemon should stick with handling the security policies. > >> 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. Do you mean zeromq or similar? Let me enumerate: for a web app, we have the following IPC hops: - between the renderer and extension process (JSON) - between the extension process (libsapi) and the sapi-daemon (zeromq?) - roundtrip between libcynara and cynara daemon (can be optimized out by caching security policy data in libcynara memory) - the rest of IPC for accessing the service (usually DBUS), perhaps peppered with other roundtrips for service-specific resource allocations. For native apps skip the first, but you have all the rest. So I think it is worth supporting and maintaining model 3 from https://wiki.tizen.org/wiki/Talk:Security/Overview (patch libdbus + dbus-daemon), since every app and existing extension will benefit from it (no need to rewrite them, and much less extra latency). > 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. Yes, doing this per vertical makes sense. Telephony will likely be done the same way. > >> 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
