Obstacles for kdbus

Posted Apr 17, 2015 9:54 UTC (Fri) by aigarius (subscriber, #7329)
In reply to: Obstacles for kdbus by mezcalero
Parent article: Obstacles for kdbus

I understand how it is more convenient to just ask the kernel to attach all the possible metadata and then, on the receiver side, decide which of it you need and how to use that. And how that removes the race conditions. That is a very good thing and a key to why kdbus is needed. On the other hand it is also understandable how the kernel developers want to minimise the outgoing information to ensure higher future flexibility.

The logging issues with a separate stream can be solved, for example by attaching a unique message id that is provided both on the log stream and to the receiver. It would be perfectly fine to see "message 123 passed from process xxx (uid:1002, ...) to process yyy (uid: 500, ...), ..." as a log entry from kdbus and then "error processing message 123: barfooed" from the receiver.

I mean - does the receiver even *need* to know the pid of the sender? Would it not make more sense to have some filter in the kernel, so that only messages from processes that actually have some capability ever reach the receiver? With an established user base of dbus it should be possible to actually find out what filters people are using and what metadata actually is critical for the receivers.

The existing security model of dbus as described in http://article.gmane.org/gmane.linux.kernel/1930451 is at best confusing. That is a clear example of something that needs to change in how dbus works and should have been changed even without the push to kbus. And once it is clear that kdbus *must* be different from dbus, then you can easily find other places to improve and clean up the protocol as well as ways to paper over those changes in libdbus or by providing a new, more convenient userspace library.

I am, admittedly, nowhere near an expert on this, but I do prefer the experts to come together with an open mind on the requirements of all sides. Without accusations of personal attacks.

Obstacles for kdbus

Posted Apr 17, 2015 12:26 UTC (Fri) by pizza (subscriber, #46) [Link]

> The existing security model of dbus as described in http://article.gmane.org/gmane.linux.kernel/1930451 is at best confusing. That is a clear example of something that needs to change in how dbus works and should have been changed even without the push to kbus

And that is a non-starter, because DBUS is an established standard that has been in use for nearly a decade.

Obstacles for kdbus

Posted Apr 18, 2015 11:09 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (2 responses)

> I mean - does the receiver even *need* to know the pid of the sender?

Yes. I'm implementing the SecretService API in keepassx and I'm locking it down so that access is based on a per-application basis (so a malicious app can't rummage around once it is open). Determining the binary is dependent on the executable pointed to by /process/PID/exe. I'd be grateful for better solutions, but that's the best I can do right now. I'm pretty sure it isn't subject to PID races since the reply won't be hooked up if it gets replaced (though exec could happen I suppose).

Obstacles for kdbus

Posted Apr 18, 2015 18:44 UTC (Sat) by nybble41 (subscriber, #55106) [Link] (1 responses)

> ... I'm locking it down so that access is based on a per-application basis.... Determining the binary is dependent on the executable pointed to by /process/PID/exe.

Unless you're doing something to prevent LD_PRELOAD and ptrace(), I'm not sure what you intend to accomplish by this. Even ignoring any potential PID race conditions, the code which is running and has access to the message bus is not determined solely by /proc/PID/exe.

Obstacles for kdbus

Posted Apr 18, 2015 19:11 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Currently, kwallet and gnome-keyring have a single "unlock" state at the collection level (though ISTR kwallet also gating based on the app, access was still global once permitted). Once, say, Firefox unlocks the store, any app can go in and query passwords. To me, it doesn't make sense to allow Firefox access to passwords intended for Pidgin or git, and vice versa (and they can even delete each other's passwords). As for the actual code running, yeah, something better would be nice, but it's more to minimize leaking if an application does have problems. It's already a pain to migrate dozens of accounts to a password store in the first place and I don't want to imagine trying to get back once malware starts targeting password stores (either by quietly siphoning, deleting, or modifying passwords in them) through the apps which communicate with them.