|
|
Log in / Subscribe / Register

A backdoor in xz

A backdoor in xz

Posted Mar 30, 2024 23:34 UTC (Sat) by mchehab (subscriber, #41156)
In reply to: A backdoor in xz by himi
Parent article: A backdoor in xz

> Services telling the service manager "hey, I'm running!" makes it much /much/ easier to have robust systems.

System V init systems are typically a lot more robust than systemd ones, as:

- the order where servers start is fixed; no risk of starting a process too early;
- jobs are started in sequence. Things like Network were started before network daemons like sshd, apache, etc;
- no parallel jobs during init/shutdown time;
- critical jobs that should never be stopped could also be added to the /etc/inittab. They were respawned if something bad happens and the process ends dying.

Also, the "hey, I'm running" task is really simple: if a process has problems, it shall die. PID 1 shall detect it and take the appropriate action when this happens. Modifying the daemon's source, specially with OOT patches sounds a very bad idea.

So, while systemd offers lots of flexibility, in terms of system's robustness, simpler usually means more stable and more reliable. I'm yet to see a systemd-based system more reliable than a SysV one. At best, it might be equivalent in terms of robustness.


to post comments

A backdoor in xz

Posted Mar 31, 2024 1:14 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> - jobs are started in sequence. Things like Network were started before network daemons like sshd, apache, etc;

What about wireless or VPNs?

> Also, the "hey, I'm running" task is really simple: if a process has problems, it shall die.

A Java server that I have for telephony takes 2 minutes to start up. How would you detect that?

There's also a problem with double-forking. The only process that can detect the death of a double-forked server is PID 1, and in classic SysV all it did was to reap the PID. Ditto for inittab - it can't detect the death of double-forked processes.

A backdoor in xz

Posted Mar 31, 2024 1:38 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link] (2 responses)

> What about wireless or VPNs?

What about it? Both work fine for me, I have 3 VPNs and occasionally wireless (tethering via my phone).

> A Java server that I have for telephony takes 2 minutes to start up. How would you detect that?

Well, for one thing, I wouldn't use Java, and I wouldn't use a server that takes 2 minutes to start up. Other than that, there are plenty of solutions for this that you could easily implement in sysvinit (you can run whatever you want whenever you want, after all, it's just a shell script); OpenRC actually handles it natively (and has since before systemd existed).

> The only process that can detect the death of a double-forked server is PID 1

That's not true (PR_SET_CHILD_SUBREAPER).

> in classic SysV all it did was to reap the PID

How is that an argument for systemd?

> Ditto for inittab - it can't detect the death of double-forked processes

Huh? inittab is a config file.

A backdoor in xz

Posted Mar 31, 2024 3:51 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> What about it? Both work fine for me, I have 3 VPNs and occasionally wireless (tethering via my phone).

Now try to make sure that the daemon does not come up until at least one network interface is up. Or until the VPN connection is established.

> That's not true (PR_SET_CHILD_SUBREAPER).

That's true in classic SysV. The subreaper was introduced only in Linux 3.4

> Huh? inittab is a config file.

If you're talking about SysV "simplicity", then you should at least learn it. Classic inittab supports respawning processes on death (action=respawn).

A backdoor in xz

Posted Mar 31, 2024 6:18 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link]

> Now try to make sure that the daemon does not come up until at least one network interface is up. Or until the VPN connection is established.

Done and done.

> That's true in classic SysV. The subreaper was introduced only in Linux 3.4

... okay?

> If you're talking about SysV "simplicity", then you should at least learn it. Classic inittab supports respawning processes on death (action=respawn).

I know it, thanks. That's not a separate program. That's part of init. Controlled by the configuration file, inittab. If you're going to act like you know something better than someone else, then you should at least learn it.

A backdoor in xz

Posted Mar 31, 2024 1:58 UTC (Sun) by himi (subscriber, #340) [Link] (4 responses)

If SysV init systems are actually more robust than systemd ones, it's because they're much simpler - your description captures that simplicity really neatly, in fact.

Though I don't actually believe that claim - I've had plenty of SysV init based systems that were massive pains in the neck to deal with, while the majority of the systemd based systems I've managed have been fairly benign and well behaved, despite doing a whole lot more. Also, the issues I have to deal with generally have nothing to do with systemd, and when they /are/ issues with the unit configuration they've been much easier to resolve than similar issues with init scripts ever were.

Oh, and writing a service targeting a SysV init environment is /far/ more of a pain than writing the same thing targeting a systemd environment - in fact, it's ridiculous how easy it is to target systemd with a basic service. No daemonising, no futzing around with logging targets, no pid files, even the kind of basic intra-service coordination you're pooh-poohing is ridiculously simple. And no mess of spaghetti shell code init script! Most of the time the unit file for a basic service is five or ten lines, and they're simple and declarative with no complex logic - infinitely easier to write and debug. Even when you need to set up complex interdependencies it's generally simple to configure and relatively easy to debug - it can be fiddly, but that's mostly inherent to the problem, rather than an artefact of systemd's implementation.

SysV init worked okay in its day, though it was always a bit of a pain. But it's long /long/ past the time when people should have recognised how much of an improvement systemd is, in pretty much every way. Eulogising the past is all well and good, but actual current performance matters a whole lot more in the real world than sepia-tinted memories of past glories.

Here too

Posted Mar 31, 2024 2:05 UTC (Sun) by corbet (editor, #1) [Link]

Fighting the old systemd wars yet again is not going to help us address this kind of attack. Please, let's not do that.

A backdoor in xz

Posted Mar 31, 2024 3:13 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link] (2 responses)

Indeed, simpler is better. Simpler is easier to secure, simpler is easier to develop, simpler is easier to maintain (i.e. run a system with it), simpler is easier to modify, simpler is easier to troubleshoot, simpler is easier to understand.

A backdoor in xz

Posted Mar 31, 2024 13:00 UTC (Sun) by pizza (subscriber, #46) [Link]

> Indeed, simpler is better.

You can have your remberberries, but the rest of us have to deal with the real world.

...The real world isn't simple, hasn't ever been, and has only trended towards higher complexity.

A backdoor in xz

Posted Apr 1, 2024 14:08 UTC (Mon) by farnz (subscriber, #17727) [Link]

FWIW, by porting a system from SysV init to systemd, I was able to close several hard-to-reproduce bugs, since systemd's extra complexity allowed me to remove a ton of complexity from the various scripts that started components of the system, and at least some of that complexity turned out to have race conditions in it that systemd did not have.

There is a huge advantage to one implementation of something done well replacing (in my case) 5 different implementations, all with different bugs.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds