The rest of the 6.10 merge window [LWN.net]

The rest of the 6.10 merge window

Posted May 28, 2024 16:13 UTC (Tue) by bluca (subscriber, #118303)
In reply to: The rest of the 6.10 merge window by pbonzini
Parent article: The rest of the 6.10 merge window

Yeah, trivial stuff like a complete D-Bus library, session management APIs and device events handling. Couple of lines that can be copy pasted with no trouble.

The rest of the 6.10 merge window

Posted May 28, 2024 16:51 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Also, having a DBUS implementation in a library that gets loaded into every process is NOT a point of pride.

The rest of the 6.10 merge window

Posted May 28, 2024 17:55 UTC (Tue) by daroc (editor, #160859) [Link] (3 responses)

I think this is getting somewhat off topic; the technical details of how mseal() could or couldn't be used by systemd are interesting. Relitigating systemd's design decisions is both not really relevant to that, and unlikely to come to anything when nobody seems to be changing their mind.

So let's please end this thread (and the related one with Lennart) here.

The rest of the 6.10 merge window

Posted May 28, 2024 20:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

I'm sorry, but I think the design decisions related to libsystemd are absolutely relevant here. mseal() interaction with dynamic loading seems to be relevant, as is the possible future pinsyscalls() analog.

libsystemd is certainly not the only offender, glibc with NSS and PAM modules is another example. But glibc is moving in the _opposite_ direction and has removed dynamically loaded libpthread.

And I don't think that the overall systemd design is in question here, just the libsystemd part. And for the record, I _love_ systemd infrastructure in general.

The rest of the 6.10 merge window

Posted May 28, 2024 20:49 UTC (Tue) by daroc (editor, #160859) [Link] (1 responses)

I do agree that it's interesting to know how mseal() interacts with dynamic loading, and that design decisions of systemd touch on that. The message I responded to seemed to me to be getting away from that -- and also to be somewhat confrontational. If you had said something like "And having a DBUS connection in every process is a source of unnecessary complexity, since many processes do not use it", I wouldn't have said anything.

I definitely don't want to stop you an bluca from having an interesting conversation about the future of this technology and the systemd project. I do really like the details we get from discussions in the comments; I just wanted to try and prevent another heated argument like the one we had this past weekend. We ended up having to turn on comment moderation for that article, so perhaps I'm just being overly-sensitive to comment moderation right now.

Please do talk about how mseal() will or will not change things for systemd. Please don't get heated about it.

The rest of the 6.10 merge window

Posted May 28, 2024 20:51 UTC (Tue) by daroc (editor, #160859) [Link]

(And, I should say -- this naturally applies to everyone. I'm not trying to single out Cyberax. Let's all remember to remain polite, respectful, and informative, like the box above the comment submission form says)

The rest of the 6.10 merge window

Posted May 28, 2024 17:56 UTC (Tue) by bluca (subscriber, #118303) [Link] (3 responses)

Usual rubbish. What you, again, fail to understand, is that it's there for free, given there _will_ be multiple processes actively using those APIs, which means the shared library is already loaded in memory by the kernel, and cached among all processes using it. So there is (next to) no extra cost if you don't need it, and if suddenly requirements change and you do need it, you get it for free.

The rest of the 6.10 merge window

Posted May 28, 2024 20:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

The question here is not just the overhead (though it IS an issue for containers), but the attack/failure surface. I don't think it's good that every application now has DBUS interface code, just out of pure design cleanliness perspective. Even if it's mostly dormant.

The rest of the 6.10 merge window

Posted May 28, 2024 22:19 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

THIS!

Does this mean any attacker who manages to hijack my program, now has access to DBUS with my credentials?

Not that I understand DBUS in the slightest, but the less code there is in my programs that I don't understand, the happier I am.

And that is actually a real danger - if I'm clueless about DBUS (because I don't knowingly use it), then how am I supposed to defend myself against its misuse (and more to the point - why should I have to)?

Cheers,
Wol

The rest of the 6.10 merge window

Posted May 28, 2024 22:36 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

The entire point of arbitrary code execution in a process context is that you can execute arbitrary code, not just whatever code already existed in the process.

The rest of the 6.10 merge window

Posted May 29, 2024 16:40 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

You're right, it's actually much worse than I remembered.

I was referring basically to sd-daemon.h. Those are the only bits that are of interest to projects outside systemd. If you want to keep it as a .so, move everything else out of the way; but they shouldn't be in the same place as journal, D-BUS and everything else.

The rest of the 6.10 merge window

Posted May 29, 2024 16:51 UTC (Wed) by bluca (subscriber, #118303) [Link]

> Those are the only bits that are of interest to projects outside systemd.

A quick search for 'sd_bus_message' on Github, excluding the systemd org, shows ~12700 results, and that's just one subset of one family of APIs, so I'm going to go with a big and fat <citation needed>

> If you want to keep it as a .so, move everything else out of the way