Re: Automotive Message Broker security
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 : > 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 > IVI@lists.tizen.org > https://lists.tizen.org/listinfo/ivi -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre ___ IVI mailing list IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi
Re: Automotive Message Broker security
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 IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi
RE: Automotive Message Broker security
Hi Kevron, We (security) should help work with you on this. Best Regards, John -Original Message- From: IVI [mailto:ivi-boun...@lists.tizen.org] On Behalf Of Rees, Kevron Sent: Monday, July 07, 2014 2:47 PM To: ivi@lists.tizen.org; d...@lists.tizen.org Subject: Automotive Message Broker security 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? -Kevron ___ IVI mailing list IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi smime.p7s Description: S/MIME cryptographic signature ___ IVI mailing list IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi
Automotive Message Broker security
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? -Kevron ___ IVI mailing list IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi
