Starting the kdbus discussions

[Lennart Poettering]

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

> This has the unfortunate side effect that now every single existing daemon needs
> to be modified to add access control, and possibly security framework specific
> code. Although it may be a reasonable solution for the system bus, I am more
> worried about how to handle access control on the session bus. In order to
> properly confine applications, there needs to be a way of enforcing file-grained
> access control to the session bus, depending on the specific permissions we give
> to the confined application.

Well, please note that policy doesn't exist in dbus1 for the session
bus. So you are into entirely new territory here anyway. That said, given that
app sandboxing authorization might involve inetractivity too it looks
like the best approach to just extend Policykit for this usecase, too.

> >> 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.
> 
> That's unfortunate. Everything uses dbus now, an all or nothing access control
> isn't sufficient to enforce a reasonable policy for confining untrusted
> applications.

If PolicyKit is not an option and you prefer the old XML policy, then
I'd recommend simply sticking to dbus-daemon for Ubuntu. Again, kdbus is
pretty much compatible to dbus from the app perspective, hence you don't
lose app support if you do.

Lennart

-- 
Lennart Poettering, Red Hat