Starting the kdbus discussions

[Colin Walters]

On Thu, 2014-01-02 at 11:23 -0500, Marc Deslauriers wrote:
>  Using
> Policykit for this would mean every single application that offered methods on
> the session bus would need to integrate with policykit and perform its own
> access control. I'm not even sure how you would do that if you have multiple
> untrusted applications running.

PolicyKit is just one implementation of userspace code making
authorization decisions based on the peer credentials.

It doesn't actually need to be a daemon; you could just as well have
each service daemon load a shared library that parses a text file, or
reads from a shared memory segment.

> I think kdbus needs to gain payload parsing capabilities for proper LSM
> integration in order to properly confine untrusted applications.

Now if you want the LSM to control access decisions,  you could have the
service (via shared library) call into the kernel, like the current
dbus-daemon does for SELinux.

I'd say pushing a likely very complex access control engine into the
kernel is not the way to go.  It makes sense for PolicyKit to be in
userspace.

(I'd actually like the kernel to be able to "upcall" to PolicyKit for
 some things, e.g. "can this uid access the perf syscall", but that's
 another topic)