Starting the kdbus discussions

[Marc Deslauriers]

On 13-12-26 07:04 PM, Lennart Poettering wrote:
> Heya,
>
> We today reached a milestone in kdbus development, that we have all the
> bits in pieces in place to boot a full system with kdbus as system bus
> and no dbus-daemon in the mix for it. The only missing bit is policy
> enforcement, everything else is there.
>
> This makes us comfortable to start discussion on the dbus ML regarding
> the details and what this means for the dbus spec. I have put together a
> document now that explains what we are doing and how to port a dbus1
> library over to a kdbus backend. Much of this hopefully should end up in
> the dbus spec one day.
>
> http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/PORTING-DBUS1
>
> (More information on the milestone you find here:
>
> https://plus.google.com/u/0/+LennartPoetteringTheOneAndOnly/posts/13JZ7GpyVDb )
>
> Anyway, please have a look at that document, comments welcome.
>
> Lennart
>

This is pretty interesting. Are there any benchmarks available to show what the
performance gains are when switching to kdbus?

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.

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.

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?

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?

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?

Marc.