Off-topic: D-Bus in the kernel

[Marcel Holtmann]

Hi Remi,

> > Just spotted this interesting post about putting d-bus in the kernel [
> > http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/ ]
> 
> Unfortunately, the D-Bus bus is too feature-bloated to be implemented in 
> kernel. For one thing, routing messages will be no fun, the kernel would have 
> to parse and keep track of the AddMatch requests. Arguably, a kernel-space D-
> Bus should implement signal subscription out-of-band (compare to the IP 
> multicast ioctl()s). But then it's not really the D-Bus protocol anymore.

not sure how you come to your conclusion. D-Bus is a well defined
inter-process/networking protocol and so it does make sense to implement
it in kernel space. For the signal subscription via AddMatch, there
might is some extra work needed, but surely that is not argument to not
try it.

> Feature negotiation will also make a kernel implementation more difficult. It 
> means more messages to parse and more state to keep in kernel.

Feature negotiation is done once when connecting to the bus. And it is
not using D-Bus message at all. You might wanna re-read on the feature
negotiation and authentication pieces in the D-Bus protocol.

> But I expect the worst part of a kernel D-Bus to be the security enforcement. 
> Parsing files in kernel space is a complete non-starter, and that includes 
> service files. So it might be possible to move the session bus to kernel space, 
> but I am not very optimistic about the system bus. Hmm, anyone for dbustables 
> and NetFilter-DBus?

I don't see this as a problem. Of course nobody is parsing XML files
inside the kernel, but then again, the whole security of D-Bus should be
deprecated anyway. The only security handling needed is for the owner of
the bus name for the system bus. Access to D-Bus API should not be done
by a static security policy. Using dynamic policies via PolicyKit or
something similar is a way better approach anyway.

And besides that you can just label D-Bus interfaces with SELinux or LSM
specific contexts like D-Bus already does these days. Then it is only up
to load the specific SELinux or LSM policy. Seems to be me pretty
generic and fits well into the current security framework.

Regards

Marcel