Starting the kdbus discussions

[Lennart Poettering]

On Thu, 02.01.14 13:32, Colin Walters (walters at verbum.org) wrote:

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

I'd be very careful with things like that where kernel would have to
wait for userspace to do something. It should always be the other way
round...

Lennart

-- 
Lennart Poettering, Red Hat