Starting the kdbus discussions

[Marc Deslauriers]

On 14-01-02 10:58 AM, Lennart Poettering wrote:
> 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.

Well, as I said before, we've added AppArmor support to the existing security
hooks that are there for SELinux. Although dbus-daemon didn't use policy files
for the session bus, the security support was already there, and we are
currently using it.

I'm not sure I understand the suggestion to use Policykit. When confining an
application, you want to block all access to the objects available on the
session bus, and, depending on the rights you want to grant to the specific
application, selectively allow certain paths, interfaces, method names. 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.

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

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

I'd rather use kdbus, but not at the expense of being able to enforce a central
fine-grained security policy like we are doing now on Ubuntu Touch, and will be
doing on the desktop in the near future. Sure, we could stick with dbus-daemon
for now, but ideally having dbus in the kernel would be beneficial from a
performance perspective (probably...would have to benchmark it...). Having a LSM
be able to perform fine-grained security decisions in kdbus would be ideal.

Marc.