[Dev] D-Bus + Cynara

Patrick Ohly patrick.ohly at intel.com
Tue Dec 2 09:25:26 GMT 2014

On Mon, 2014-12-01 at 19:11 +0100, Karol Lewandowski wrote:
> On 2014-11-26 15:46, José Bollo wrote:
> > Le mercredi 26 novembre 2014 à 14:48 +0100, Jacek Bukarewicz a écrit :
> >> Recent talks on the D-Bus mailing list suggest that in the future all 
> >> messages could contain connection credentials [2] which would make 
> >> integration process on the service side a bit easier. Such posts suggest 
> >> that performing checks on the service side is an approach that is 
> >> endorsed by the community. From my understanding it will also be the 
> >> suggested way of securing kdbus services.
> > That is very interesting. Thank you for that input, even if it exclude
> > the path taken by tizen.
> I would be quite worried if "path taken by Tizen" would be radically
> different from upstream's.

FWIW, Canonical is also moving ahead with their dbus-daemon patches to
secure D-Bus in combination with AppArmor. So it's not just us still
relying on dbus-daemon.

>   Ignoring community direction might cost us a lot in
> long run
>  - and I do not think anyone would be interested in that,
> I do believe we are considering this approach because:
>  (1) there is clear need for fine-grained policy checking
>  (2) upstream packages we are interested in do not implement it on
> service side
>  (3) trying to change above does seem too much work compared to gains
>        it might bring.
> ... and I agree that in above cases implementing dynamic checks in
> dbus-daemon might be great idea.


> However, what I would warn (and advise) against is delegating policy
> checks to dbus-daemon where we can implement it directly in given service without
> too much trouble (ie. all services we are *the* upstream of).

I tend to agree. However, I'm not exactly seeing the developers of those
services being particularly eager to do that work either. Has anyone
indicated that they even looked at Cynara and tried to use it in a
service? I only know of Kevron (Automotive Message Broker) and myself
(and I depend on the D-Bus patches because I need to secure upstream
D-Bus services).

> While this isn't problem for now I would encourage to really take into
> account
> that in next 1-2 years Linux systems are likely to be running without
> dbus-daemon
> at all.

It doesn't look like kdbus will be a drop-in replacement for the current
D-Bus, so services and clients will have to be adapted to use it. That
would be our opportunity to get the security checks into upstream. And
yes, that means working with upstream instead of just taking the code
and then trying to run it as-is in Tizen.

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.

More information about the Dev mailing list