HN user
"While the above attack did use the systemd vsock sshd listener for Escape to Host, the attacker could have just directly listened over the vsock loopback."
https://www.openwall.com/lists/oss-security/2026/01/08/7
TL;DR: a clueless user fails to understand and configure his own systems, but for clickbait effect chooses to blame the evil SyStEmD!!!11 instead of his own incompetence
Maintaining separate upstream sources and downstream patches does provide value. Maybe not to you, but it does.
For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. For example to see how glibc is currently customized in debian testing/unstable you can just navigate this webpage:
https://sources.debian.org/src/glibc/2.42-6/debian/patches
If everything gets merged in the same git tree it's way harder. Harder but doable with a rebase+force push workflow, which makes collaboration way harder. Just impossible with a merge workflow.
As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened.
In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through.
It gracefully falls back if the new option is not available at runtime
No, the graphics stack needs to be native and in sync for obvious reasons, and that includes the mesa libraries. What can be in the runtime is already in the runtime.
The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals.
The blog post subject of the thread literally links to the documentation. If you can't even be bothered clicking on the provided links, what are you even doing commenting on such a thread. But by all means, don't let facts get in the way of a good baseless rant.
It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an over-worked open source maintainer of a core project (xz) doing a thankless job and getting pressured left-and-right until he caved (no fault of his own), and they managed to install an updatable, generic backdoor that could be used to attack literally anything. The initial version was chosen to target sshd <-- libsystemd <-- xz.
The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers.
Idiots instead rant about "muh systemd" and use it to attack other maintainers.
I’m somewhat a fan of systemd and I’m interested in immutable images, but I don’t want to build systemd from source:
You don't have to, we build packages and publish repositories from latest main, and the particle configs can use those by enabling the 'obs' build profile
So how do I replace any of them with my own, small tool?
You write them with an equivalent public interface.
They have no stable interfaces.
This is nonsense. All the D-Bus (and now Varlink too) interfaces are stable, documented and we do not break backward compatibility.
yet nobody was able to write a replacement.
That's because actually doing things is hard, but complaining on social media is extremely easy.
The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
It is not. There are other, very real and very important problems with that fact and reasons why it should be fixed, but this is not it. The point of SecureBoot is to protect the firmware from userspace. It works very well for that purpose, as evidenced by the facts that exploits to bypass it have to continuosly be found.
When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment. There is systemd-firstboot, etc, but this is not as convenient as just being able to set config options on the mounted (non-booted) embeddded media.
systemctl --root /path/to/sd/card/ <...>
Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine
malloc_info() is not consumed internally but it is only wired up as a debugging utility via systemd-analyze, which is sorely needed when things go bad in strange and weird ways. It would be entirely fine for a libc to just implement a stub that returns a fixed string:
<malloc version="0">Not implemented</malloc>
or so.
For the record, it turned out this was just a series of misunderstandings on the part of the OP on how configuring networking works on Linux, and the differences between how the kernel and how userspace manage and configure addresses. These points have all been clarified by myself and another maintainer on https://github.com/systemd/systemd/issues/33866
- the assertion is made that networkd creates link local addresses - it does not, the kernel does.
- the assertion is made that configuring how the _kernel_ sets up link local addresses must automatically and silently affect how userspace network managers configure global addresses. This is of course not the case, and one might ask for such a feature, but its absence most definitely does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that userspace network managers independently listening on RA packets and creating SLAAC global addresses independently of the kernel must set the stable-privacy interface flag. This is not the case, such flags are owned by the kernel and cannot be set by userspace. Being absent does not mean the the addresses are not private or stable, it just means they are not kernel managed, and thus a different (RFC 7217 compliant) algorithm is used as explained on https://www.freedesktop.org/software/systemd/man/latest/syst...
- the assertion is made that the suffixes generated by the _kernel_ to set up link local addresses must automatically and silently be copied by userspace network managers to configure global addresses on the respective interfaces. This is also of course not the case, the algorithm is described in the link above, and again asking for such a new feature is fine, but its absence does not mean that it is "utterly inadequate for IPv6 or dual-stack installations".
- the assertion is made that certain defaults must be changed to meet the OP's personal preferences. This of course cannot really be done in a project like systemd, where we try our best to keep backward compatibility, even if we don't always succeed. The desired configuration is very easy to setup, for example this should suffice:
[Network] IPv6PrivacyExtensions=yes IPv6LinkLocalAddressGenerationMode=stable-privacy
[IPv6AcceptRA] Token=prefixstable
As usual, it would be best to ask clarification questions and investigate how things actually work _before_ making definitive assertions on a blog post about a component for which one has a cursory understanding at best, but that's not nearly as much fun as a good ol' systemd bashing blog post, right?
Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and storage and memory allocation bugs. All of that stuff is going to exist in whatever boot loader. Again, for an individual user, if you want to install systemd-boot, great, go ahead and use it. It's good, it works. But as a general option it's just going to have the same issues, unfortunately.
This is completely wrong though - the main point of sd-boot is that it does _not_ implement any of that - no filesystems, no fonts, no themes, nothing at all, the firmware is used to do all the risky stuff via the UEFI protocols. So it is very much not reimplementing what grub or the kernel do, the exact opposite in fact, it's the number one design goal.
Yes: it's a joke. Here, have some chills, on the house:
The fact that YOU have a particular use case doesn't necessarily mean much either. Just customize your configuration accordingly, and move on.
Or what about, delete it after 10 days it was last accessed (regardless of whether for read or write)? Hint: that's already how tmpfiles.d works
Why not just have the installer _ask_ me what configuration I prefer?
Because nobody bothered to actually put in some work to implement that. As I've said on the ML, if somebody does the work, I'll review it. But it's one of hundreds of different settings, and it's obviously not worth anybody's time to do this work, as it's largely inconsequential and trivial to configure via the supported config files. Complaining on social media is of course cheap enough that we get plenty of it.
What a genius idea, how bizarre that nobody ever thought about that before! We just need to get the bus dependencies up first and then... oh. Oh wait. Oh no.
kdbus didn't even make it into staging. Project mainline put in some serious work to get where it got. > And quite probably part of it going better was not insisting on becoming mandatory solution for everyone. If anything, it might have been less "wheelbarrows of cash" and more conflicts involving kdbus principal developer and Linus.
You mean, because it would actually be _used_ somewhere in open source distributions (that is, not just deep inside some de-facto proprietary half-closed-source fork owned by a single mega-corp)? Yeah when things are hidden away in some cupboard in the basement it's much easier not to ruffle feathers. But yeah the LKML is bad today, but back then it was a veritable open-air cesspool
The kdbus docs could do better job declaring why it's needed then.
Well, it's dead, so what's the point...
D-Bus will never be removed. Varlink was added because the kernel refused to provide usable IPC primitives, like other OSes have, so a brokered IPC is simply unfeasible in early userspace. So now we have two IPCs that will work in parallel, forever, because such is life on Linux.
That's my point: Binder got merged before kdbus started development.
It didn't, it was merged in 2015, a year after or so. No, staging doesn't count, it's a dumping ground for all sort of things that do not see the light of day.
Also, I still don't see what kind of races
Just because you don't see it, it doesn't mean it's not there. Do some research and you'll see it.
By "making it available" it doesn't necessarily mean a fully-working, configured broker, but only having enough working primitives that you can bring up userspace without races, with requests that can immediately be accepted, even if not answered until a bit later. The stuff that we currently just cannot do with D-Bus, and that we have to reinvent protocols for.
Binder predated both Bus1 and kdbus projects
It's not about when they started, it's about when they got merged/rejected. One got rejected because "ipc in kernel is bad", and some months later the other was merged because "ipc in kernel is good". One rule for thee...
kdbus/bus1 were about making IPC primitives available race-free to userspace since the very first moment it is started. Perf was icing on the cake. Binder is Google-only, so nobody else can really use it, given they might kill it at any moment.
The end result of not having bus1 is that we have to forget about brokered IPC and go back to 1:1 bespoke protocols over af_unix - ie, varlink
No, performance wasn't the main reason (although that was a big part), it was mainly about race conditions. If userspace implements the bus, then only the half of userspace that comes up after the daemon can use it. Having a reliable IPC mechanism that is available from the moment PID1 is started was the goal.
Sadly that was rejected, and Bus1 was too, because apparently it's really bad to have IPC primitives in the kernel, can't have that. Then of course 6 months later Google showed up with a few wheelbarrows of cash and Binder, and strangely all such objections evaporated and it was merged without a peep. Funny how these things go.
Me too, it's been my phone's notification sound for about 20 years now
No, the OP was not sent any harassment, the OP _did_ the harassment as it can be seen in the tweets. I mean, they are right there, just click on the links you shared. One of the OP's followers even openly called for the assassination of the project maintainer, and you have the galls to defend him? This is truly deranged stuff.
And again, there is no "vulnerability", there is simply a person that doesn't know how Linux works and has learned something new. Which again it's fine, nobody knows everything and we all learn new things everyday, it's just that normal and sensible people don't use that to make grand claims on social media and start harassment campaigns culminating in death threats.
Professional security researchers responsibly report real issues using the appropriate channels, such as defined at: https://github.com/systemd/systemd/security/policy this is not the work of a researcher, this is a grifter looking for self-promotion on social media.
The only thing this demonstrates is that the author has no clue about how these things work on Linux. There is no real security boundary between different processes of the _SAME_ uid, especially when controlling the parent process. The exact same "hijacking" can be done to literally any other tool, including sudo. Or you can take over the X11 session and sniff passwords and whatnot. Or heck you can just append alias sudo='mykeylogger sudo' into bashrc and go to the pub instead of having to wait for the right process to start at the right time. If you have write and execute privilege of a user, anything that user does can be compromised.
The reality is that this is just self-promotion from a grifter, and that's why it's happening on Twitter. If it was a real issue from a competent researcher it would have been reported via the appropriate channels, not on social media to feed haters and trigger the usual abuse and death threats while chasing impressions.
As a trade-off you now have a user-accessible IPC system with the _gazillion_ possible vulnerabilities it entails. At least before you needed root to talk to pid1..
Read the linked post again. This is all already available, and always has been, since forever.
Requires root not just for the ptrace protection, but also to gain membership of the 'tty' group which gives control over all ttys. And then goes all surprised pikachu when it turns out that allows taking over ttys. Duh?