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

The rest of the 6.10 merge window

Posted May 27, 2024 22:13 UTC (Mon) by aszs (subscriber, #50252)
In reply to: The rest of the 6.10 merge window by Cyberax
Parent article: The rest of the 6.10 merge window

ok... considering that change would have blocked the XY backdoor, apparently a naive use of mseal() would be a step backwards... and it sounds like in this case preventing transitive dependencies from setting IFUNCs would be the most obvious hole to plug.

to post comments

The rest of the 6.10 merge window

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

The correct change would have been splitting the libsystemd into libmeaculpa and libjournald. Where libmeaculpa would have contained only the basic systemd interaction functionality (readiness and other housekeeping features) and libjournald would have had everything to do with the journal (including decompressors). It also would have solved the problems with the ssh, but without adding tons of new infrastructure.

The rest of the 6.10 merge window

Posted May 28, 2024 8:24 UTC (Tue) by bluca (subscriber, #118303) [Link] (15 responses)

Do you really have to repeat this nonsense under every article? It's really tiring, you obviously have no idea how any of this works the way it does and why, so how about you just drop it? Pretty please?

The rest of the 6.10 merge window

Posted May 28, 2024 12:25 UTC (Tue) by diegor (subscriber, #1967) [Link]

Do you have a link to the rationale of why not splitting the library? I'm quite interested to know why.

Thanks.

The rest of the 6.10 merge window

Posted May 28, 2024 15:07 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (13 responses)

But it's true. There's parts of libsystemd that are simple stuff, that has already been implemented dozens of times and that should be a simple copylib rather than a shared library. The rest is the journal.

Using libsystemd for the former is just laziness as things stand. As a copylib it makes more sense.

The rest of the 6.10 merge window

Posted May 28, 2024 16:13 UTC (Tue) by bluca (subscriber, #118303) [Link] (12 responses)

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:42 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Yet compressor dependencies are only needed for the journal part. Unless I'm missing something?

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