Starting the kdbus discussions

[Greg Kroah-Hartman]

On Tue, Jan 07, 2014 at 10:40:39PM -0600, Tyler Hicks wrote:
> On 2014-01-07 17:30:32, 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 :)
> 
> The discussion is really about where the line gets drawn between kdbus
> metadata and kdbus payload (sd_bus_message). I'm suggesting that we can
> move the line over just a little from where it is at now and gain some
> real security benefits by doing so.
> 
> The D-Bus spec clearly calls these fields (with the exception of the
> message type) "Header Fields":
> 
>  http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-header-fields
> 
> I don't think I'm too far off my rocker by arguing that they should also
> be considered header fields by kdbus. :)

Is the name of the kernel module confusing people?  We can rename it to
be "kbus" if the "d" is causing problems.

> > > 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.
> 
> These fields are pretty intrinsic to D-Bus. If they go away or change,
> we're talking about something different than kdbus at that point.

The kernel code is not handling the "dbus" protocol as you think of it,
it's quite different.  There's no need for the kernel to know this
information, so let's not waste time in parsing/handling it at all.

> > 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.
> > 
> > Don't make the kernel do the work just because you find changing the
> > kernel easier than userspace projects, that's lame.
> 
> That's not the reason that I'm proposing this, at all. LSMs are in the
> kernel, the audit subsystem is in the kernel, and now D-Bus may end up
> in the kernel. It just makes sense to let the LSMs and audit have access
> to the D-Bus metadata in the kernel, too.

The userspace library is still needed to make things look like "D-Bus",
that's not going away, so your hooks/filtering should still be just
fine, right?

thanks,

greg k-h