On Mon, 16 Jun 2014 16:43:08 +0000 "Schaufler, Casey" <[email protected]> said:
> > -----Original Message----- > > From: Dev [mailto:[email protected]] On Behalf Of Dominig ar Foll > > Sent: Monday, June 16, 2014 1:06 AM > > To: [email protected] > > Subject: Re: [Dev] The SAPI proposal > > > > Hello, > > > > I would like to remmeber yopu that the concept of SAPI has been > > introduced in order to enable the provision of a Native API support as > > required by some profiles without having to create two independent > > security frameworks. > > Native application support is hypothetical. I suggest that before > we sink time and money into a solution to the native framework > problem we define the native framework. That way we can > determine if our solution solves the problem we have. I am > averse to implementing SAPI without a clear understanding > that it will be necessary and sufficient to address the problem. i have a distinct feeling that sapi as a simple wrapper around native apis is going to fall flat on its face for performance reasons. this will essentially make every api call a round-trip to a service (that has to be created). this works in the wrt because it doesn't have to be a round-trip cross-process. it can be inlined into the interpreter. so discussing an interpreted runtime like wrt (or python, etc.) that can forcibly insert per-api access logic isn't relevant to native code. to forcibly insert logic for native code means either: 1. make it a system call and do it inside the kernel or 2. proxy via a syscall (make it ipc) and do the security logic in another process you trust, and give access only to this process. sapi wants to do #2, but this is going to be horribly inefficient, unless you carefully design a protocol that keeps in mind the overhead of going cross-process. even the syscall option is heavy. so you design a protocol domain-by-domain that does things like async operation, batching and delivering large chunks of data via shared memory (mmap etc.) or maybe using fd passing to finally grant unrestricted access to something (eg network access - once your connection is approved for your process, the service connects for you and then hands you the fd). my point here is, that to have both security and acceptable performance means apis have to be designed to batch and be async by default. that means changes in api and changes in whoever uses them. this also has to be done carefully domain by domain. there is no quick "one size fits all with no breakage" solution without paying another major price - performance. so is it worth doing all of this for that price? i'd say no. i'd say - let's not take shortcuts. also keep in mind, performance loss is invariably battery life loss too. these things matter. > > In Tizen 2.x the security was directly managed by the WRT and Native > > application had no security model. > > > > In Tizen 3 we know that some profiles will require the support of Native > > and Hybrid Applications. If we follow the same path than in 2.x we will > > need to implement a security model in Crosswalk (the new WRT) and create > > an other one for Native Apps. > > > > Not only this double the double the work, it also increase security risk > > as it is unlikely than the two frameworks will behave the same. > > > > Adding a unified security framework in Tizen is a model which would push > > to the level of Android. > > > > I understand that it is far away from traditional Linux desktop, but > > that is not what we are targeting with Tizen. > > > > Regards > > > > Dominig > > > > > > Le 13/06/2014 15:37, José Bollo a écrit : > > > Hi Zoltan, > > > > > > On ven, 2014-06-13 at 13:25 +0300, Kis, Zoltan wrote: > > >> On Thu, Jun 12, 2014 at 5:50 PM, José Bollo > > > (SNIP) > > >>> - 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. > > > The profile IVI is using murphy. The profile mobile is also using a > > > specialized component to arbitrate resources. SAPI doesn't aim to > > > replace any of them but instead aims to cooperate with them when > > needed > > > if needed. > > > > > > It is hard to give an example. The only one that is coming to me is > > > related to an other kind of problems: switching the resource from an > > > application to an other when the former is going to be paused in the > > > background while the other is activated in front. > > > > > >>> - 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? > > > Core API uses DBUS in some parts but the question of handling > > > asynchronous signals/listener isn't fully solved currently. What I can > > > say is that Core API doesn't expose dbus interface. It defines all the > > > types and callback itself using the good old c. It will be easy to add a > > > verb to dispatch events. Core API is maybe using a kind of ecore loop in > > > some cases, what is an other difficulty, but I still have to check (Help > > > welcome). > > > > > >> 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. > > > That is what we dont want to do: making a general purpose libdbus. And > > > it is why using Core API is good: because it is hiding details while > > > bringing what is needed to implement the well defined TIZEN APIs (web > > > and native). > > > > > > (SNIP) > > > > > >>> 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. > > > What is system API? If libc then the answer is no, it is out of the > > > scope of SAPI that concentrate on Core API. > > > > > >> 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)? > > > I'm sure that there is a notion of session. Cynara defines a such > > > notion. I dont know if murphy also defines it. I'm thinking that a > > > session is more dynamic, it is "on need". > > > > > >>> 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. > > > Agreed. See above. > > > > > > (SNIP) > > >>> 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? > > > Yes. Ideally, the transport part is changeable. But there is at least > > > one feature needed: passing file descriptors. > > > > > >> 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. > > > Agreed. > > > > > >> 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). > > > It also have drawbacks 8( Thank you for having check that talk page. > > > Dont hesitate to add your comment on it, it is intended for. > > > > > >>> 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. > > > (SNIP) > > > > > > Best regards > > > José > > > > > > _______________________________________________ > > > Dev mailing list > > > [email protected] > > > https://lists.tizen.org/listinfo/dev > > > > -- > > Dominig ar Foll > > Senior Software Architect > > Intel Open Source Technology Centre > > > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
