@coyote @ScatmansWorldFSE @kino UID 0, PID 1.
> Doesn't it run as a more privileged user than even the root user?
For one thing, init can't die; if it does, the kernel panics. It's got the "unkillable" flag set on it (kernel/fork.c). Control-Alt-Delete gets translated to a signal sent to init. (Don't quote me on this, but I believe other interrupts also end up getting handled by init.) There's nothing that can keep tabs on it, really, since it's got control of the system before anything else can exist.
This wouldn't be a problem if it could be demonstrated that the code is not compromised: it'd have to be short, readable, and self-contained. But systemd is none of those, and not only that, it leaves the front door wide open: it initializes the hardware, opens and accepts connections, and exchanges traffic with the network before any other processes have even started. It'd be hard to conceal an exploit in a normal init system, except that if there's any vulnerability in any of the network code, that's a door into the process's memory space, and how the hell are you going to even log it if the disk isn't mounted and the only process running on the machine is compromised? It serves at least DNS and HTTP, and has clients for at *least* DNS, HTTP, NTP, DHCP, sometimes builtin and sometimes through a library. Good fucking luck!
Maybe if systemd had super-hardened, verifiable network code, that'd be less ridiculous, but it doesn't. It just links against whatever version of whatever library sometimes, and their track record on input validation is so shameful that Lennart ought to be banned from ever touching a computer: if your username started with a digit, systemd gave you root permissions. (I'M FUCKING SERIOUS:
https://www.theregister.com/2017/07/05/linux_systemd_grants_root_to_invalid_user_accounts/ . CVE-2017-1000082.) Poettering went full WONTFIX on the issue, like he had with many others: he's got a long and storied history of complaining that security bugs aren't real, that CVEs aren't helpful and shouldn't exist, and closing down security bugs without discussion while complaining of persecution by evil developers.
:zz40::zz95::zzea::zz3f::zz40::zz95::zzea::zz3f::zz40::zz95::zzea::zz3f:
Here are some choice CVEs, use-after-free, network code, etc.:
CVE-2018-15687
A race condition in chown_one() of systemd allows an attacker to cause systemd to set arbitrary permissions on arbitrary files. Affected releases are systemd versions up to and including 239.
CVE-2018-15688
A buffer overflow vulnerability in the dhcp6 client of systemd allows a malicious dhcp6 server to overwrite heap memory in systemd-networkd. Affected releases are systemd: versions up to and including 239.
CVE-2018-16866
An out of bounds read was discovered in systemd-journald in the way it parses log messages that terminate with a colon ':'. A local attacker can use this flaw to disclose process memory data. Versions from v221 to v239 are vulnerable.
CVE-2019-3842
In systemd before v242-rc4, it was discovered that pam_systemd does not properly sanitize the environment before using the XDG_SEAT variable. It is possible for an attacker, in some particular configurations, to set a XDG_SEAT environment variable which allows for commands to be checked against polkit policies using the "allow_active" element rather than "allow_any".
CVE-2019-3844
It was discovered that a systemd service that uses DynamicUser property can get new privileges through the execution of SUID binaries, which would allow to create binaries owned by the service transient group with the setgid bit set. A local attacker may use this flaw to access resources that will be owned by a potentially different service in the future, when the GID will be recycled.
CVE-2020-13529
An exploitable denial-of-service vulnerability exists in Systemd 245. A specially crafted DHCP FORCERENEW packet can cause a server running the DHCP client to be vulnerable to a DHCP ACK spoofing attack. An attacker can forge a pair of FORCERENEW and DCHP ACK packets to reconfigure the server.
CVE-2020-1712
A heap use-after-free vulnerability was found in systemd before version v245-rc1, where asynchronous Polkit queries are performed while handling dbus messages. A local unprivileged attacker can abuse this flaw to crash systemd services or potentially execute code and elevate their privileges, by sending specially crafted dbus messages.