As I do not think that the D-bus transport will be used in a final product where the socket transport will provide more the performances which are expected, we need to define a security model which is not realted to D-Bus but rather generic.
Something in the still of the Application manifest translated to the CAN Zones would likely be a viable model. Thoughts ? 2014-07-09 14:03 GMT+02:00 Patrick Ohly <[email protected]>: > On Mon, 2014-07-07 at 14:46 -0700, Rees, Kevron wrote: >> i've listed some use cases that define WHAT needs to be secure in >> Automotive Message Broker (AMB). The next question is "HOW"... >> >> https://wiki.tizen.org/wiki/AMB_Security >> >> The security policy engine needs to know the user and zone of the >> requesting process id. Can cynara be used like this? > > Cynara at the moment only knows about privileges; AMB concepts like > individual properties and zones seem to be a poor match for that. But > I'll let you discuss that with John and the Cynara developers. Please > report back to the list with a summary. > > My question is something else: AMB uses a publish/subscribe model for > property changes, and one transport for that is D-Bus. See > org.freedesktop.DBus.Properties.PropertiesChanged in > https://wiki.tizen.org/wiki/AMB_DBus_Plugin. > > If we stick to the original plan (services call cynara or do their own > privilege checking), then you cannot use D-Bus signals with unset > destination and rely on dbus-daemon to route the signal to interested > recipients, because your service won't know who is subscribed via a > watch filter (*) and the dbus-daemon doesn't know who of the subscribers > are allowed to receive the signal. > > (*) The Wiki page mentions that AMB tracks if someone is interested in a > property change, but that's not what dbus-daemon uses. > > You could send out one PropertiesChanged signal per client calling > Manager.Find, addressed specifically to that client, but that is less > efficient. > > Have you thought about deprecating the > org.freedesktop.DBus.Properties.PropertiesChanged API in favor of some > other transport? Not sure whether that is an option, considering that > D-Bus is the IPC mechanism used in GENIVI. > > How often do such signals get emitted? D-Bus may be a poor match also > for performance reasons. > > If you need to keep the current API and want to avoid sending one signal > per recipient, then dbus-daemon needs be enhanced such that it can check > whether a certain subscriber is allowed to receive a certain signal. In > user-space dbus-daemon, this could take the object path into account. It > cannot be based on the actual property, because that is a detail that > dbus-daemon doesn't know about. > > In KDBus it'll be even worse; there the object path is part of the > opaque payload and thus not available for routing decisions. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > > > _______________________________________________ > IVI mailing list > [email protected] > https://lists.tizen.org/listinfo/ivi -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
