Everyone, Sorry for reacting to this so slowly. (Copying genivi-dev for info.)
On 5 Aug 2014, at 07:53, Dominig ar Foll (Intel OTC) <dominig.arf...@fridu.net> wrote: > Le 05/08/2014 00:58, Rees, Kevron a écrit : >> On Mon, Aug 4, 2014 at 3:45 PM, Schaufler, Casey >> >> <casey.schauf...@intel.com> wrote: >> >>> We should start looking at using Cynara for application >>> (W3C) privilege enforcement. >>> >> I need to get with John to talk about whether Cynara would best be >> used inside AMB or at the crosswalk-extension level. It's on my TODO >> list. >> > > It shall be done in AMB directly in order to allow non HTML5 Apps to benefit > of the security. This is in particular critical when the socket transport > mode is used as there is in that case no other security enforcement point. I'd just like to request the AMB project and other component developers to consider not integrating too tightly with specific technologies. Having the AMB tightly interact with Cynara might (depending on how you do it) effectively make it a Tizen-only component. Will you be able to do it in a generic and replaceable way? Dominig - discussing a pattern for adapting "generic" services to Tizen in a non-intrusive way would be good, IMHO. Let me elaborate. Except from Tizen IVI, there might be no other GENIVI compliant platform that uses Cynara, and I doubt that it will be possible to require it as the only solution for service access policy enforcement. In this case I consider AMB to be a potentially generic component. AMB is a project that has been followed by GENIVI since its inception and was proposed by the Networking EG to be included into GENIVI compliance specification. (It was withdrawn due to some technicalities, but that does not change the point for the future; it is still usable in GENIVI systems). It's probably OK for the "special daemons" (as we called them in the GENIVI/Tizen joint F2F; not sure if there is another name). They use a freely defined communication over sockets, and are in their code project strongly tied to the corresponding Tizen Core API. Tight interaction with other Tizen-only technologies should be fine there because those components are basically Tizen-unique anyway. But as Tizen moves into implementing its security mechanism also for D-Bus and integrating other generic services I would propose to also consider non-Tizen systems. If we aim for a modular and generic approach for any generic component there is the potential for broader reuse. In particular the security enforcement mechanisms is an area with much variation in different distros, so keeping its integration flexible would be good. Finally, this is probably a non-issue but just in case: for any component that you *do* make such changes to I would like to remind everyone to be diligent with popular versioning principles (likely best described by http://semver.org/). Those are also used in GENIVI. Specifically, if there is any incompatible API change (which I suppose an enforced security policy is), then the major number should be increased on the released version. This will match how GENIVI uses version numbers in its specifications. It will avoid the risk of an already released GENIVI spec (which frequently requires a component version N <= [used-version] < N+1), to be after-the-fact matching what has later become an incompatible component. Thanks for considering, - Gunnar -- Gunnar Andersson Lead Architect, GENIVI Alliance Infotainment, Volvo Car Corporation > > Dominig > _______________________________________________ > IVI mailing list > IVI@lists.tizen.org > https://lists.tizen.org/listinfo/ivi > _______________________________________________ IVI mailing list IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi
