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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
