This article was never meant as a comparison between existing federated and decentralized protocols. But we do take up the challenge for the next, good idea!
As a fun project we hacked a C interpreter (based on tinyCC) that compiles C code in-memory and runs it live. CJIT today is a 2MB executable that can do a lot, including call functions from any installed library on Linux, Windows, and MacOSX.
This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that.
A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and due to systemd's call to dlopen() liblzma library (CVE-2024-3094). The resulting build interferes with authentication in sshd via systemd.
Please take the systemd trolling to Reddit. They likely targeted xz specifically because it’s so widely used but there are dozens of other libraries which are potential candidates for an attack on sshd, much less everything else which has a direct dependency unrelated to systemd (e.g. dpkg).
Rather than distracting, think about how the open source projects you use would handle an attack like this where someone volunteers to help a beleaguered maintainer and spends time helpfully taking on more responsibilities before trying to weaken something.
Those other libraries dependend on by sshd are hopefully more closely monitored. The upstream sshd developers probably did not even consider that liblzma could end up being loaded in the process.
Make excuses for systemd all you want but loading multiple additional libraries into crytical system deamons just to write a few bytes into a socket is inexcusable and directly enabled this attack vector.
You are distracting from facts with speculations and trolling FUD. I refer to what is known and has happened, you are speculating on what is not known.
Your claim is an appeal to emotion trying to build support for a position the Linux community has largely rejected. Starting with the goal rather than looking unemotionally at the facts means that you’re confusing your goal with the attackers’ – they don’t care about a quixotic attempt to remove systemd, they care about compromising systems.
Given control of a package which is on most Linux systems and a direct dependency of many things which are not systemd - run apt-cache rdepends liblzma5! – they can choose whatever they want to accomplish that goal. That could be things like a malformed archive which many things directly open or using something similar to this same hooking strategy to compromise a different system component. For example, that includes things like kmod and dpkg so they could target sshd through either of those or, if their attack vector wasn’t critically dependent on SSH, any other process running on the target. Attacking systemd for this is like saying Toyotas get stolen a lot without recognizing that you’re just describing a popularity contest.
Actually you have a point. A collection of shell scripts (like the classical init systems) have obviously a smaller attack surface. In this case the attacker used some integration code with systemd to attack the ssh daemon. So sshd without systemd integration is safe against this specific attack.
In general, I’m not convinced that systemd makes things less secure. I have the suspicion that the attacker would just have used a different vector, if there was no systemd integration. After all it looks like the attacker was also trying to integrate exploits in owner libraries, like zstd.
Still I would appreciate it, if systemd developers would find a better protection against supply chain attacks.
It’s also tricky to reason about risk: for example, ShellShock caused a bunch of vulnerabilities in things which used shell scripts and the classic SysV Init system was a factor in a ton of vulnerabilities over the years because not having a standard way to do things like drop privileges or namespace things, manage processes, difficulties around managing chroot, etc. meant that you had a bunch of people implementing code which ran with elevated privileges because it needed to do things like bind to a low network port and they either had vulnerabilities in the privileged part or messed up some detail. I think in general it’s been much better in the systemd era where so much of that is builtin but I have been happy to see them starting to trim some of the things like the compression format bindings and I expect this will spur more.
I really appreciate your tone and dialectic reasoning, thanks for your reply. And yes, as simple as it sounds, I believe that shell scripts help a lot to maintain mission critical tools. One hands-on example is https://dyne.org/software/tomb where I took this approach to replace whole disk encryption which is nowadays also dependent on systemd-cryptsetup.
3. Aren't =, != etc. used to compare strings and -eq, -ne, -gt etc. used to compare numbers? I see lot of numbers compared as strings, e.g.:
[ $? = 0 ]
[ $? != 0 ]
[ $exitcode = 0 ]
4. There are lot of "cat <<EOF" blocks without indentation. I understand that this is made because the shell expects "EOF" on the line start, but there is a special syntax designed on purpose for this use case, simply put a dash between << and the token, e.g. "cat <<-EOF".
In this case:
tomb_init() {
system="`uname -s`"
case "$system" in
FreeBSD)
cat <<-EOF
create=posix_create
format=posix_format
map=posix_map
mount=freebsd_mount
close=freebsd_close
EOF
;;
Linux)
thanks for your review! tho you are referring to the tomb-portable unfinished experiment which is about to be dismissed since cross-platform experiments with veracrypt show very bad performance.
you are welcome to share a review of the tomb script, but be warned in that we use a lot of zsh specific features. It is a script that works since 15+ years so it has a discrete amount of patchwork to avoid regressions.
It is 10 and more years that I experience such ad-hominem attacks.
You are so quickly labeling an identifiable professional as troll, while hiding behind your throwaway identity, that I am confident readers will be able to discern.
Our community is swamped by people like you, so I will refrain from answering further provocations, believing I have provided enough details to back my assertion.
The people's appreciation we get is impressive: desktop Linux users (a 3% niche in the world, I know...) really like Devuan and, in general report a better experience on distros without systemd, see https://distrowatch.com/dwres.php?resource=ranking
thanks for posting the news here, there is a lot of love and attention to detail in Daedalus <3
IMHO we should maintain GNU/Linux/BSD systems as tools that can free us, not entangle us or turn us into guinea pigs.
The world is already full of proprietary systems, including the one produced by the employer of systemd. WSL has improved a lot in the past years, he should be focusing on that, or at least use that as a testing ground.
Not confining new technology like systemd has lead to an infinite amount of CVEs to deal with in the past years, this could have been avoided by not allowing a tech prototype to bypass community adoption and impose itself as a ego-driven standard.
Just saw the video and must say that it has really sparked my interest in Devuan. I heard of Devuan when the fork was first announced but never gave it much notice, now is the first time I try to understand what it really is. It seems like Devuan is much more organized and well-thought than I imagined. This is music to my ears:
Devuan will do its best to stay minimal and abide to the UNIX philosophy of "doing one thing and doing it well". It will foster diversity and freedom of choice among all its components and will perceive itself not as an end product, but as a a process, a starting point for developers, a viable base for sysadmins and a stable tool for people who have enough experience with computers. Devuan will never compromise for more efficiency at the cost of the freedom of its users, rather than leave that and the responsibility for
a secure setup to downstream developers.
I need to do much more research and of course testing, but Devuan could be light at the end of the tunnel.
I need to make much more research before I will convince anyone, but as a start I like the philosophy of Devuan very much.
I have moved many many servers from Debian to FreeBSD after the announcement of systemd, and this has been great, but I must agree with you that on the desktop it can be a little inadequate.
I used my own C code generator for CGIs for years, along mongoose for other tasks. Nowadays I'm using https://kore.io and I'm VERY happy with it, great developer experience, well written and understandable code, minimal in dependencies and no bugs so far. I'm using it quite heavily in a project, it was easy to add templating and other amenities to it. Highly recommended.
