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