[Dev] D-Bus + Cynara

Jacek Bukarewicz j.bukarewicz at samsung.com
Fri Aug 1 15:40:39 GMT 2014


> ...
> Approaches
> ==========
> We have two possible ways of securing D-Bus services:
>       1. A D-Bus service calls Cynara and rejects to do things which are
>          not allowed. It can reply with an error or simply ignore
>          messages (TBD, see below).
>       2. The dbus-daemon asks Cynara whether a) a client is allowed to
>          send a certain message and/or b) whether it is allowed to
>          receive one (for signals).
> ...

I believe option 2 is better. As you've described dbus daemon is already 
responsible for enforcing security.
Extending it so it uses Cynara (and maybe other services) sounds like a 
good idea.
I'm thinking of starting work on patching dbus daemon. Initially just to 
probe potential issues we can get into.

> ...
> Filtering
> =========
> With rules as outlined above, we can filter by source, destination,
> interface and member. Filtering by interface and member will be
> problematic in KDBus because they are part of the opaque payload that
> KDBus knows nothing about. When relying on these message attributes for
> filtering, a different approach will be needed if and/or when the
> services switches to KDBus.
kdbus developers suggest that native kdbus services perform their own 
policy enforcement (for example via Cynara or Polkit). [1]
Legacy dbus services have an option of using bus proxy which uses kdbus 
and also exposes socket which uses same protocol as the
one used by the dbus daemon. It is also responsible for enforcing 
security policy. For this reason if we're going to switch to kdbus at 
some point, patching bus proxy would be one option.
Making services use kdbus natively and enforce security directly via 
Cynara - another one.

[1] http://lists.freedesktop.org/archives/dbus/2014-January/015926.html

Best Regards,

Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
j.bukarewicz at samsung.com

More information about the Dev mailing list