Starting the kdbus discussions

[Jamie Strandboge]

On 01/08/2014 02:51 AM, Lennart Poettering wrote:

> 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.
> 
I find it quite interesting that this thread is called 'Starting the kdbus
discussions' yet there is an apparent lack of desire to listen to what the
community needs. Sure, there has been a lot of back and forth but it keeps
ending with essentially 'sorry, go away', often with some sort of put down.
While I wasn't at Plumbers, I got the impression from Tyler and John (who did
attend and talked about kdbus with Greg) that there was a willingness from
upstream kdbus to work with the wider community if people wanted to do the work,
but this attitude has been lacking in this thread. In fact, up until a few
minutes ago, we've been told in this thread that patches will be categorically
rejected.

In an effort to keep things constructive, as Tyler said, we're talking about
moving the line ever so slightly between kdbus metadata and payload so that
kdbus retains some of the existing headers in the metadata and is therefore more
in line with the current D-Bus specification[1]. This shouldn't greatly
complicate things and systemd, Portals, SElinux, etc should be able to just
ignore these headers if they choose. We'd be delighted to work with kdbus
upstream to make this happen, with code if people would review and seriously
consider it.

Why do we keep harping on this? Because it allows for fuller and finer-grained
mediation than what kdbus currently can offer at the connection level. Mediation
at the connection level works fine when you trust the service and its API
completely, but this isn't always the case: the service can be under attack,
malicious in some way or badly programmed. Then there is the API-- obviously
some service's APIs may have methods that are unsuitable for unprivileged
processes, which is one reason why PolicyKit exists and while PolicyKit is put
forth as what should be used for this sort of thing, you have to trust the
developer of the service to implement it properly (there have been many CVEs
over the years for mispropgrammed use of PolicyKit). Sure, we can avoid
PolicyKit and have a library that these services could link to to do the heavy
lifting to enforce system policy, but that doesn't solve the case of when the
service is under attack or malicious and will just avoid the library. We could
also do some sort of proxy or write a new message system in the kernel, but we'd
very much rather work with kdbus.

By retaining these D-Bus headers in the metadata, an LSM is in a position to
wrap these services if it wants to. kdbus is in kernel. With kdbus, the boundary
between processes using D-Bus is in kernel. The LSM is in kernel. Mandating that
part of the system security policy is in userspace creates an unnecessary
awkward split for those that want to implement finer-grained security in the LSM
like we do now with AppArmor[2]. Note, Ubuntu isn't the only distribution that
uses AppArmor and I can easily imagine other LSMs being interested in the
ability to mediate beyond the connection level.

Greg had an interesting comment: 'Is the name of the kernel module confusing
people?  We can rename it to be "kbus" if the "d" is causing problems.' Indeed,
but why then are kdbus upstream sending this to dbus at lists.freedesktop.org and
asking to discuss "the details and what this means for the dbus spec"?

Let me be very clear, we want to use kdbus and to participate in its development
and we want to work with upstream to make kdbus something that the wider D-Bus
community can use. At this point, I was going to write, "how can we make this
happen?" since we seemed to be at an impasse. However, based on Greg's last
email, it sounds like patches will be thoughtfully considered and that there
actually is a path forward to work together on the best technical solution.

Thanks

[1]http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-header-fields
[2]As mentioned previously in the thread, dbus apparmor patches are forthcoming

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140108/e80c0f3a/attachment.pgp>