Starting the kdbus discussions

[Marcel Holtmann]

Hi Marc,

>>>> Hi Lennart! I've added Greg to cc since John Johansen and I spoke with
>>>> him about this in a hallway at Plumbers last year.
>>>> 
>>>> On 2014-01-02 18:08:42, Lennart Poettering wrote:
>>>>> 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.
>>>> 
>>>> I agree that parsing the payload in the kernel is not something that we
>>>> should do. However, I do think that there are some important metadata
>>>> fields hidden away in the opaque sd_bus_message that should be exposed
>>>> to the kernel by way of moving them to the kdbus_msg.
>>>> 
>>>> I'm proposing that the following fields be moved to the kdbus_msg:
>>>> 
>>>> - message type
>>>> - destination
>>>> - sender
>>> 
>>> These three you have anyway, in one way or another. (or can mostly
>>> reconstruct from the data available to the kernel, since the kernel can
>>> distuingish method calls from method replies and broadcast signals --
>>> though you cannot distuingish methods replies from method errors).
>>> 
>>>> - path
>>>> - interface
>>>> - member
>>> 
>>> Nope. This is really not how this is supposed to work. These concepts
>>> are opaque to the kernel on purpose.
>> 
>> So you're not willing to change any of your design to cope with the community's
>> requirements?
>> 
>>> And the kernel does not use them
>>> for anything. We are certainly not adding arbitrary fields to the kernel
>>> structures, which nobody needs,
>> 
>> We're arguing the point that the kernel does need to use them, so the LSMs can
>> make appropriate security decisions.
> 
> Then in your LSM, parse things out.  There's nothing stopping that from
> happening, but don't force all other users to have the overhead, and
> complexity, that they do not need here.

let me give a simple analogy here. You are also not sending HTTP headers along with your TCP/IP socket. So neither should kdbus require any extra metadata that is not needed to transport payload. At the end of the day kdbus is a routing protocol to move messages from process A to process B. It needs enough information to do exactly this and nothing more.

If any LSM needs to look into kdbus payload, then it has to do it by itself. There is also no other way to do it since you can not trust that userspace fills in the right metadata that matches the payload. If you would blindly trust that userspace does the right thing, then you security model has a major flaw already right there.

Regards

Marcel