Starting the kdbus discussions

[Kay Sievers]

On Thu, Jan 2, 2014 at 2:46 PM, Marc Deslauriers
<marc.deslauriers at canonical.com> wrote:
> This is pretty interesting. Are there any benchmarks available to show what the
> performance gains are when switching to kdbus?

No, not really. At least no direct comparison. Simple benchmarks to
compare different systems are in the kdbus and systemd repos, but they
do not compare to dbus-daemon:
  https://plus.google.com/+KaySievers/posts/PrFZMYihbXS

> In the PORTING-DBUS1 document, you mention that the kernel will not do access
> filtering by userspace payload, and that policy enforcement needs to be done by
> the receiving process. This is quite a big change from the current dbus-daemon,
> and is going to remove functionality we are depending on.

Right, the actual payload is opaque to the kernel. Only metadata is
added to a bloom filter, and the kernel filters on that data. Due to
the nature of bloom filters, that cannot be used to provide any sort
of security.

> We are about to submit a patch that adds AppArmor mediation alongside the
> current SELinux mediation in dbus-daemon. This allows us to properly confine
> untrusted applications with AppArmor and enforce a fine-grained policy on path,
> interface and method names, not only for the system bus, but for the session bus
> as well.

That cannot work in the kernel that way.

> Are there any plans on extending the kernel support to be able to parse the
> userspace payload and ensure proper LSM integration? How do security frameworks
> such as SELinux and AppArmor fit into kdbus?

They will probabaly work on the primitives only, like who can talk to
which peer, who can own which set of names. Just like SELinux works
for sockets, the kernel in this case will also never look into the
payload of sockets.

It needs to be so sorted out, we haven't talked to the SELinux guys so
far, it will happen soon.

> Won't removing the existing policy files from the system bus prevent a system
> administrator from customizing and locking down an installation for specific use
> cases?

It would, that would need to happen in the daemons themselves then, or
in PolicyKit and not in D-Bus policy.

> Desktop environments that use dbus run on other operating systems besides Linux.
> Do you intend kdbus as a compliment to dbus-daemon, rather than a replacement?
> Are there any plans on modifying dbus-daemon to remain compatible with the kdbus
> changes so applications that are using kdbus features can still run with
> dbus-daemon?

No, dbus-daemon will be entirely out of the picture on systemd
systems. Maybe someone will port parts of it, or teach dbus-daemon new
things, but we do not plan to work in that direction.

Kay