Starting the kdbus discussions

[Lennart Poettering]

On Thu, 02.01.14 08:46, Marc Deslauriers (marc.deslauriers at canonical.com) wrote:

> 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.

The kernel enforces simple Unix-ACL-like access control. i.e. for each
service the policy contains whether a specific user can send to, receive
from or own it. Any more finegrained access control then eneds to be
done by the services themselves. I think in most cases simply checking
the client's capability set is sufficient for the various methods a
service might provide, the same way as the kernel statically checks
specific capabilities of clients calling syscalls. For the cases where
where more complex access checks should be done we recommend people to
use PolicyKit, as it is a lot more expressive and supports interactive
authentication and suchlike.

> 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?

I figure this will be pretty close to the AF_UNIX+SOCK_DRGAM model for
these LSMs.

> 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?

For the cases where that's desirable PolicyKit should fill the void fine.

> 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?

On a legacy free systemd Linux system I'd expect no dbus-daemon anymore
in a year or two. On other Unixes, and on Ubuntu and suchlike I figure
people will still use dbus-daemon. For apps the diffeerence between the
backends should be small, though system services certainly would have
more to gain by taking advantage of kdbus' features.

> 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. Client libraries that support kdbus should continue support dbus1,
so that apps don't have to care whether the backend they end up using is
kdbus or dbus-daemon.

Lennart

-- 
Lennart Poettering, Red Hat