Starting the kdbus discussions

[John Johansen]

On 01/08/2014 12:51 AM, Lennart Poettering wrote:
> On Tue, 07.01.14 15:24, Tyler Hicks (tyhicks at canonical.com) 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.
>>
>> 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
It was how dbus worked.

> are opaque to the kernel on purpose. And the kernel does not use them
yes

> for anything. We are certainly not adding arbitrary fields to the kernel
they aren't arbitrary. It is a very specific set from the original dbus
spec

> structures, which nobody needs, which cannot be checked or validated by
> the kernel, and complicate things and create a false sense of security
they can be validated to the same level userspace can do for a coarse
level object/method level policy.

> via a flawed security model... 
> 
sorry no. At least no more than Intents or portals. Admittedly they can
not provide the same level of validation as service drilling down into
the method/object data but they do provide a first pass, and can be
used in conjunction with the service/app where appropriate

> Really, we will not parse dbus messages in the kernel, and we will not
> work around this design choice by then just moving arbitrary fields from
> the userspace to the kernelspace header. 
> 
again not arbitrary

> You can do such things with dbus-daemon, or you can create a bus proxy,
> like we did for compat reason, but the kernel should not look into the
those are both possibilities

> payload like this or even have an understanding of so many userspace
> details.
> 
the kernel really doesn't have an understanding of the details. The policy
abstracts this out. Its really not that different from other places policy
is loaded and enforced in the kernel.

> It's a bit like you'd write a letter with salutation, sender/receiver
> addresses and valediction, which you then seal into an envelope, on
> which you write sender and reciever address, then break the seal again,
> and fax both the envelope and the letter to the destination....
> 
no its not.

>>  1) The kernel provides a centralized, trustworthy location for making
>>     security decisions
>>     - The security burden isn't placed solely on the clients/services
>>     - LSMs could hook into kdbus and perform fine-grained filtering,
>>       much like what's possible in today's dbus-daemon
>>     - kdbus security policy for an application can be located alongside
>>       the security policy for other kernel-managed objects (files,
>>       network permissions, IPC objects, etc.)
>>     - The D-Bus security policy could be fine-grained, allowing filter
>>       on certain interfaces, members, etc.
>>     - I suppose that someone could even write an LSM to implement the XML
>>       bus policy if they had a dependence on it
> 
> This really misses the point. We get rid of the XML policy because it is
> misdesigned, and not just because we want to replace XML by somer other
> formatting.
> 
hrmmm it has its place, and certainly still will be an issue for some
distros for quite a while. Being able to support this policy would be
nice but certainly isn't the only goal.

> You cannot replace decisions PolicyKit is capable of by a decision
> engine in the kernel. That's because PolicyKit can ask questions
> interactively, can ask the network and whatnot. Trying to avoid fixing
yes, it certainly has its place and should be used. There is no question
of this. But interactivity is not needed for all decisions and the
kernel is the trust boundary between directly communicating processes.

> things properly by moving all complexity and all understanding of the
> userspace semantics into kernel space is never going to work. In
right. Nor are we asking or trying to do that.

> addition, in many many cases looking at the mere method call
> interactions between clients and servers will not work anyway, if you
> don't have any context for it.
> 
yes we are aware of that

>>     - If the burden of auditing is placed on a client/service, they
>>       will not likely have the required privileges (CAP_AUDIT_WRITE) to
>>       write to the audit subsystem
> 
> auditd can also just subscribe to the monitor stream and get the data
> without further intervention of the kernel, if auditing on that level is
> really desired.
> 
hrmmm that gets some of what is desired but has its own issues

> Sorry, but this is not happening. Find a different solution. Use
> dbus-daemon, provide a bus proxy that enforces your ruleset, or hack up
> your own kernel IPC, but kdbus is not going to do what you want it to
> do.
> 
Well we are trying to work with the community, and raising an issue we
see with the currently proposed kdbus. If nothing comes of it at least
the issue was raised and discussed at which point we have to evaluate
options, but believe it or not working with the community is preferred