A backdoor in xz [LWN.net]

A backdoor in xz

Posted Mar 30, 2024 6:55 UTC (Sat) by intelfx (subscriber, #130118)
In reply to: A backdoor in xz by mchehab
Parent article: A backdoor in xz

> Why systemd would possible require any integration with sshd?

To signal (and receive) the readiness state of the daemon in question. Not more, not less.

> IMO, systemd should return to its roots and stop requiring interactions with other packages unrelated to PID 1's task.

I'd say that "reliably determining whether the supervised process has successfully started up" (i. e. loaded and parsed its configuration, bound all the necessary sockets, did not encounter any other failures) is very much within the definition of the PID 1's task.

to post comments

A backdoor in xz

Posted Mar 30, 2024 22:57 UTC (Sat) by mchehab (subscriber, #41156) [Link] (1 responses)

> > Why systemd would possible require any integration with sshd?

> To signal (and receive) the readiness state of the daemon in question. Not more, not less.

System V init never needed that, as there are simple generic solutions to monitor that. Basically, when a process is forked on a child process and such child dies, the parent is notified. This a well-defined POSIX-defined behavior.

> > IMO, systemd should return to its roots and stop requiring interactions with other packages unrelated to PID 1's task.
>
> I'd say that "reliably determining whether the supervised process has successfully started up" (i. e. loaded and parsed its configuration, bound all the necessary sockets, did not encounter any other failures) is very much within the definition of the PID 1's task.

It shall be up to sshd process - and to all other system daemons - to die if it failed to parse configuration and/or bind necessary sockets. The task of PID 1 is to monitor if the process is dying too fast, and, on such cases, to take some action.

There's absolutely no need to modify system daemons, implementing non-POSIX out-of-tree hacks just for PID 1 to be aware that a process is up and running.

A backdoor in xz

Posted Mar 31, 2024 2:07 UTC (Sun) by intelfx (subscriber, #130118) [Link]

> System V init never needed that

Yes, and it sucked.

> This a well-defined POSIX-defined behavior

The fact that it is well-defined or POSIX-defined does not automatically mean that it's _good_. I hate to break it to you, but POSIX is not a pinnacle of system design.

> It shall be up to sshd process - and to all other system daemons - to die if it failed to parse configuration and/or bind necessary sockets

Setting up a proper readiness notification by double-forking is approximately tenfold more complicated and requires exponentially more moving parts than the sd_notify mechanism.

In fact, many daemons (including openssh) do not complete their initialization until after the fork, so the only correct implementation of the interface you describe entails the immediate child _waiting_ for the grandchild to finish its setup, and only then exiting. Which means that there has to be a temporary pipe or socket between the child and the grandchild.

So now we are choosing between a socket notification mechanism implemented _once_ in a well-audited, well-maintained project (systemd) and **the same socket notification mechanism** plus a bunch of historical nonsense implemented _all over again_ in each daemon.

I trust the choice is obvious.

A backdoor in xz

Posted Apr 4, 2024 15:34 UTC (Thu) by koh (subscriber, #101482) [Link] (1 responses)

> To signal (and receive) the readiness state of the daemon in question. Not more, not less.

Why would liblzma be needed for that?

A backdoor in xz

Posted Apr 4, 2024 15:44 UTC (Thu) by cjwatson (subscriber, #7322) [Link]

It's not any more (following https://github.com/systemd/systemd/pull/31550 and https://salsa.debian.org/ssh-team/openssh/-/commit/cc5f37...).