Starting the kdbus discussions

[Kay Sievers]

On Thu, Jan 2, 2014 at 6:08 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> On Thu, 02.01.14 11:23, Marc Deslauriers (marc.deslauriers at canonical.com) wrote:

>> 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.
>
> If you require this feature, then kdbus is explicitly not something you
> should look into. Ubuntu has to find a different solution there, sorry.

Right, the kernel will not look into the payload.

Not until the kernel itself will become a bus and offers it's own
objects there. But that is something unrelated, and which can be
discussed years from now in the future, not today.

There are also no plans to give in-kernel LSMs access to the payload.
Please do not expect anything like that to happen. The kernel should
not be involved in parsing (otherwise entirely opaque) payload.

What kdbus offers though is separate "endpoints" which can carry their
own more restrictive policy:
  https://code.google.com/p/d-bus/source/browse/kdbus.txt#41
But that is also does not cover any decision on the payload or
per-interface/object setting, it's the same dumbed-down
unix/kernel-like policy the kdbus system bus uses, nothing similar to
the old D-Bus policy.

Kay