Starting the kdbus discussions

[John Johansen]

On 01/07/2014 05:30 PM, Greg Kroah-Hartman wrote:
> On Tue, Jan 07, 2014 at 03:24:28PM -0600, Tyler Hicks wrote:
>> 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.
> 
> So, you want to parse the payload :)
> 
no, we just disagree about what is payload and what is header information.
One of the nice things about dbus, that gave it an advantage over using
another ipc mechanism was that it had extra header information that was
well defined. This allowed the bus to enforce policy on communications
at a course api level.

Without this you can't be fully compatible with the dbus spec, hence
kdbus not supporting dbus policy

>> I'm proposing that the following fields be moved to the kdbus_msg:
>>
>>  - message type
>>  - path
>>  - interface
>>  - member
>>  - destination
>>  - sender
>>
>>  (Note that the destination string is already being tacked onto the
>>   kdbus_msg, as a kdbus_item, when a well-known name is used for the
>>   destination.)
> 
> What happens when we come up with a different payload type?  The kernel
> doesn't care about the payload, so please, don't make it parse it, as
> there's nothing there that it could even do anything with.
> 
then the header information would reflect that its a new type. And policy
would ignore or disallow it dependent on how the policy was written.

> If you want to create a security model that does deal with the specifics
> of the payload being sent through kdbus, then put it in the library that
> does the talking to the kdbus interface in userspace, like you do today.
> 
Ah but its not like today. Today the dbus is a separate process, that is
privilege separated and can have a different security type/domain.

By moving the bus into the kernel, the kernel is the privilege boundary
between the communicating processes. We can't just move the enforcement
into a library in userspace because then we must trust the service/
application to enforce the mandatory policy, whether that is the current
dbus policy or some new extended policy (by say an lsm).

We can't trust the application/service to correctly use the library to
enforce the policy because the application is capable of by-passing the
library code that does the policy enforcement; either through shims and
calling into different function points, binding in its own version of the
library, or through custom code.

For trusted apps the issues remain to a degree as they might be compromised
in which case they can no longer be trusted. There is also the issue of how
trusted the application/server doing the mediation is, to do the mediation
it will need privileges to call out the enforcement engine (policy kit, LSM
whatever), possibly kill processes that are sending bad messages or trying
to DOS it etc. Some of these are privileges you may not want to give
the service. And yes we are sticking trusted apps/services into a security
domain to help mitigate against the possibility of compromise, and keep
them to minimum required privileges.

> Don't make the kernel do the work just because you find changing the
> kernel easier than userspace projects, that's lame.
> 
No its not that we have done it in userspace, if anything doing it in
the kernel is harder. It an issue of where the privilege separation and
trust boundaries are.