I do have sshd disabled, I unselected it at install/setup time.

So far I have not been able to disable systemd . Which was not supposed to be on my Slackware system in the first place. I never installed systemd, did not notice any other package installing it. How did systemd get there? Slackware tells everyone it does not use systemd. A week ago I would not have cared so much. But now knowing there is a backdoor into systemd, I do care.

There is NOT a back door into SystemD (as far as we know). There ALMOST was a back door into SystemD, but that problem has been solved. Still, SystemD is an unneeded vulnerability in my opinion. And, yes, I also care. I never liked SystemD, but now I have about 6 more reasons why.

Could you be more specific, _exactly_ what have you found on your Slackware system that you are calling systemd, and that you cannot disable?

I am running openSUSE Tumbleweed on this machine.

CPE OS Name: cpe:2.3pensuse:tumbleweed:20240404:*:*:*:*:*:*:*


Thinkcentre-M57p:~> xz -V
xz (XZ Utils) 5.4.6
liblzma 5.4.6
Thinkcentre-M57p:~> ldd /usr/sbin/sshd | grep 'lzma|systemd'
Thinkcentre-M57p:~>

-Thanks

Here's Bruce Schneier's take on this.

3 members found this post helpful.

Um, that grep isn't testing what you think it is (though looks like your xz version is too old for this attack anyway).

Very interested how you claim to have that trojan aka systemd installed on your Slackware machine.
Could you please run this command in cli and paste it here?
systemctl --version

Hi, I thought to show information on the openSUSE machine here:

Thinkcentre-M57p:~> systemctl --version
systemd 255 (255.4+suse.22.g56b53b17bc)
+PAM +AUDIT +SELINUX +APPARMOR +IMA -SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK -XKBCOMMON -UTMP +SYSVINIT default-hierarchy=unified

-Thanks

1 members found this post helpful.

Hey man, you're about a week too late for April fool's day.
I can't tell if you're trolling, but in case you're not: Slackware doesn't use systemd.

2 members found this post helpful.

First I tested for whether systemd sockets were active,
setting (in my unbound.conf) to use only systemd sockets,
unbound ran fine with no errors.

Then I looked around for files/links named "systemd". There
were too many to post here. But here is a small sample.

run/systemd
var/run/systemd
sys/fs/cgroup/systemd
usr/include/elogind/systemd

proc/1/cwd/run/systemd@
proc/1/root/run/systemd@
proc/10/cwd/run/systemd@
proc/10/root/run/systemd@
proc/1000/cwd/run/systemd@
proc/1000/root/run/systemd@
...
...
...
proc/self/cwd/run/systemd@
proc/self/root/run/systemd@
proc/thread-self/cwd/run/systemd@
proc/thread-self/root/run/systemd@

systemd appears to being running on process 1, and quite a few others.

Considering that the xz threat of controlling systemd had to do with how systemd (among other things) controls logins and could be given a backdoor -

- then the freely confessed use of "elogind" for slackware's logins, when elogind contains all of the login code from systemd including any weakness in systemd's login security

- then the difference in login security between systemd vs elongind is only a matter similar to how you pronounce potato and tomato.

As far as I have read right now, it is only gnome and kde which must have systemd/elogind. And I use neither of those.

As of now, I am considering a major distro leap. I am in the process of installing void linux. When they say "no systemd", they appear to sincerely mean it. I have not yet found any files named "systemd".

The 'cwd' and 'root' directories under the process directories are just symlinks to /

What you're seeing there are symlinks required by elogind.
It's not:
So remove it:
Hmmm: https://docs.voidlinux.org/config/se...anagement.html Good luck!

2 members found this post helpful.

Whilst the xz backdoor may be related to systemd, the presence/absence of systemd in Slackware is entirely off-topic and should be discussed in a distinct thread.

Please keep posts in this thread on the topic of XZ Utils being backdoored, and the security concerns which directly surround that event.

(If any moderators can split posts 13..19 and 21..26 into a new thread, that'd be helpful; I sent in a report but the only listed moderator for this section hasn't been active in over two years.)

1 members found this post helpful.

https://lcamtuf.substack.com/p/techn...he-xz-backdoor

https://marc.info/?l=openbsd-misc&m=171179460913574&w=2

While it's easy to blame systemd for everything, this was malicious code implanted by malicious actors in a carefully prepared supply chain attack, which was meticulously planned and executed - and most likely state sponsored. If systemd didn't exist, those same actors would adjust their code/mode of attack to target whatever else.

Debian/Ubuntu and Red Hat based servers running systemd are the biggest target and more likely to be found in corporate/government, so of course they hit those rather than something very obscure.

But yes, a lot of questions arise from this... but for me they're questions about the broader issue of Linux security as a whole, rather than just systemd.
This was as a result of an upstream Linux/systemd specific patch to xz-utils. It was not a patch to OpenSSH as you seem to think.

OpenSSH is developed by the OpenBSD project and had nothing to do with this patch to xz-utils.

xz-utils maintainer-ship was taken over from the original author by another developer - you can read a plethora of articles about this and what is currently known - many linked here.

I'm with you on the use of elogind, but I feel you're flagging up a lot of false positives. The entries in procfs for example are most likely harmless.

You may find systemd related entries in /proc as well as systemd unit files, even when systemd is not installed - this is most likely due to upstream software which has systemd support and may be used by elogind if that's installed.

However, your conclusions seem quite alarmist and not based on any actual problems. Clearly you see the word "systemd" and you're jumping to conclusions... you're not alone.

This used to happen a lot, maybe still does for all I know, with Devuan the "systemd free" distribution based on Debian. The "zealots" who migrated to Devuan used to complain endlessly if any file whatsoever called "systemd" (such as "libsystemd0" or some unit files) appeared to be installed - without any real understanding of what those files were or the reasons they were there. This was/is fairly typical of Devuan and the "cult like" following it gained - intentional or not - and instead of ignoring these zealots, the distribution maintainers mostly appeased them, because Devuan (understandably) did not want to lose users. Unfortunately that reluctance to lose users and tolerance towards the intolerable has harmed the project and driven people away - only to be replaced by users with the same kind of hysterical, alarmist views you've been posting here.

1 members found this post helpful.

Bruce Scheier reports that further review has shown that the attack on xz was not a one-of.

1 members found this post helpful.

We can thank our lucky stars it is all open source and subject to review/scrutiny.
Were these projects closed source, we would be up the proverbial &^%$ creek without a paddle.