Starting the kdbus discussions

[John Johansen]

On 01/02/2014 09:08 AM, Lennart Poettering wrote:
> On Thu, 02.01.14 11:23, Marc Deslauriers (marc.deslauriers at canonical.com) wrote:
> 
>> 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.
> 
> Well, it's generally not applications talking to other
> applications. It's mostly applications talking to desktop services. And
Except when you start allowing application to advertise or replace services,
this is done all the time in android.

> those I believe should just come with PolicyKit hooks. I am pretty sure
> having apps talk to other apps is something a good sandbox should
> prohibit entirely.
> 
Sometimes, but often you want to be able to punch holes in the sandbox
and selectively allow things based on a policy.

>> I think kdbus needs to gain payload parsing capabilities for proper LSM
>> integration in order to properly confine untrusted applications.
> 
> I am sorry, but to make this very clear: this is explicitly not an
> option. There will not be a payload parser for kdbus in the kernel, as
> long as the four developers who are working on it have any say. The
> entire design is based on the concept that the payload is irrelevant to
> the kernel, and routing is done only according to the metadata we
> attach. This is a fundamental design decision of kdbus, and the four of
> us (Kay, Daniel, Greg and I) will refuse this.
> 
Well its not so much a matter of parsing the payload, as what is payload
and what is header. The information we use was part of the header in dbus,
but has been mostly removed from it in kdbus.

> If you require this feature, then kdbus is explicitly not something you
> should look into. Ubuntu has to find a different solution there, sorry.
> 
possibly