Starting the kdbus discussions

[Simon McVittie]

On 08/01/14 08:51, Lennart Poettering wrote:
> On Tue, 07.01.14 15:24, Tyler Hicks (tyhicks at canonical.com) wrote:
>> 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.
...
>>  - path
>>  - interface
>>  - member
> 
> Nope. This is really not how this is supposed to work. These concepts
> are opaque to the kernel on purpose.

Here is a technical justification for the positioning of the dividing
line that has been used in kdbus is at least logically consistent.
(kdbus people, if there are other reasons why it's the right place to
draw the line, please articulate them.)

The sender, destination and coarse message type (unicast "conversation
start" (method call or unicast signal) vs. broadcast signal vs. unicast
reply) are available for the kernel's decision-making. They are also
used in-kernel for message-routing: if the kernel('s security policy)
doesn't trust a process to respond correctly to a message, it can drop
that message on the floor, and the process will simply never see it.

The object path, interface, method name and fine message type (method
call vs. unicast signal, successful reply vs. error) are *not* used by
the kernel for message-routing: rather, they are used within the
destination process to route the message to a component. If you don't
fully trust the destination process (or worse, you think it might have
been subverted), it's logical to assume that you also can't fully rely
on it to route messages according to the object path, interface and
method name in the way they were intended.

Similarly, suppose you have a privileged service (like NetworkManager,
for instance) which performs a mixture of unprivileged functions ("tell
me whether I'm online") and privileged functions ("configure my
network"), discriminated by interface and method name. In "classic"
D-Bus, it can either set a different access control policy for those
methods ("the old way"), or allow all of those method calls through and
use PolicyKit to make authorization decisions ("the new way").

In kdbus, the "different access control policy" route is not available;
but if you don't trust the privileged service to make correct calls out
to PolicyKit, why should you be trusting it to dispatch calls correctly
by interface and method name? Either way, it's accepting input from a
less-privileged client and making its own decisions about what to do
with that input - it's a trusted system (in the sense used by the US DoD
and on <https://en.wikipedia.org/wiki/Trusted_system>).

Orthogonally, doing authorization control via PolicyKit also opens the
possibility to do asynchronous GUI authorization - "do you want to allow
this?" - which is a useful capability that seems unlikely to ever be
provided in-kernel due to its complexity.

It is of course possible to mix the two approaches: have a kernel-level
(or dbus-daemon-level) policy that only a subset of clients are allowed
to communicate with NetworkManager at all, *and* a PolicyKit-based or
other userland policy in NetworkManager which limits privileged
operations to a smaller subset.

----

kdbus proponents: you're right about this, but please try to be less
adversarial about it. Justifying why a design decision is correct,
rather than just stating that it is, produces a much less "us vs. them"
relationship from the wider community, and also acts as useful
documentation to future maintainers on why something is the way it is.

Please keep this discussion focused on the best technical solutions
rather than inter-vendor politics, and be prepared to justify technical
decisions so that we can all build the best possible systems.

Thanks,
    S