The kdbuswreck [LWN.net]

The kdbuswreck

Posted Apr 23, 2015 22:31 UTC (Thu) by drag (guest, #31333)
In reply to: The kdbuswreck by Cyberax
Parent article: The kdbuswreck

*shrug*

I like the idea of just having a generic metadata that isn't tied into anything else and allow user space to decide the format and how it's interpreted. Just let the kernel provide the mechanism and not be responsible directing the policy (besides a very simple 'is Y allowed to listen to X message bus').

Tying other kernel security interfaces into it as part of IPC information packet seems like it would be a mistake. Especially since those LSMs or capabilities (or whatever) are not necessarily appropriate for every case were daemons have to make a choice in how to respond to process requests.

At least that way it seems that kdbus working in concert with systemd would have a way to maintain backwards compatibility without having to hard code that into the kernel for all of eternity. Which seems to me what Andy is shooting for here.

to post comments

The kdbuswreck

Posted Apr 23, 2015 23:04 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (3 responses)

i'm not seeing how kdbus mandates caps usage for all of eternity.

Here's my understanding that right now with the current patches
receiver decided if it needs to have caps info or not
sender decides if it wants to send over caps.

If they agree recv and sender get to talk via the bus. If they don't.. bus doesn't relay mesgs.

If in the future every single receiver and sender on the bus decided they no longer needed to care about caps they can just stop asking for that metadata to be sent over the bus. Right?

The kdbuswreck

Posted Apr 23, 2015 23:23 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

If the kernel API says that it passes caps, it is _really_ hard to change that later without breaking something in userspace that depends on it.

This is one of the big reasons people are unhappy with kdbus, it locks a lot of dbus specific policies into the kernel API

The claim is that the only thing that should talk to it is libdbus, but we've already seen that such a policy doesn't work against the userspace dbus, so why would it work against kdbus?

The kdbuswreck

Posted Apr 23, 2015 23:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

DBUS is extensible, so in future it's certainly possible to pass additional capabilities via custom methods. The old userspace simply won't be able to use it, but that's not a big deal.

It all seems like a storm in a teacup, the current capabilities are used only for very special actions like rebooting or manipulation of system services. Basically, they are more-or-less a direct replacement of "if (sender_uid == 0)".

The kdbuswreck

Posted Apr 30, 2015 10:17 UTC (Thu) by metux-its (guest, #102293) [Link]

Actually, I never understood why tiny side cases like reboots need all that complexity.

Anybody noticed that we already have per-process namespaces ?
Oh, and we've got file permission flags since aeons.

Why not just giving things like the shutdown/reboot service their
own communication channel (ie. socket), which is only made available
to certain users or processes ? Either via perms or mounts, or by
some key authentication ?

Anybody had a look at Plan9 ?
It really could be so simple ...