Starting the kdbus discussions

[Tyler Hicks]

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
 - 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.)

Two benefits of doing this would be:

 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

 2) The kernel can produce useful, secure audit logs based on kdbus
    message flows
    - An admin may want the ability to fully configure what D-Bus events
      should be audited and the events may be conditional down to a
      certain path, interface, and member combination
    - The audit messages would be much more useful because they could
      contain these fields in a readable form
      + The same goes for error messages
    - 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

I can't really think of any significant negatives to moving these fields
to the kdbus_msg. Routing should not need to be changed. There may be
some technical headaches that I'm not seeing while reading the code but
it seems to be about as simple as moving the fields from one struct to
the other.

Of course, we'll have to do some basic sanity checks on these strings,
when there is a subsystem that wants to consume them, but that's no more
complex than what kdbus is already doing for connection names in
kdbus_name_is_valid().

By moving these fields to kdbus_msg, the kernel doesn't have to parse
the sd_bus_message payload and we get powerful security features built
into kdbus.

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140107/2c632515/attachment.pgp>