A backdoor in xz

Posted Mar 30, 2024 12:11 UTC (Sat) by bluca (subscriber, #118303)
In reply to: A backdoor in xz by MarcB
Parent article: A backdoor in xz

It's needed to compress/decompress journal files and coredumps. The former is done also via a public sd_journal* set of APIs hence it is in libsystemd.so. In git main we switched to dlopen these libs only when needed - ie, when the sd_journal API is called _and_ it encounters a file compressed with the corresponding lib.

This will be the dependency tree of a fully-featured build of libsystemd in the next release:

build/libsystemd.so.0 (interpreter => None)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

Compression libs and libgcrypt will all be dlopened on demand, if needed.

A backdoor in xz

Posted Mar 30, 2024 13:58 UTC (Sat) by pbonzini (subscriber, #60935) [Link] (5 responses)

I wonder however if simple and common functionality like notification and file descriptor retrieval belongs in the same public-facing library as reading the journal and the coredumps. Perhaps they should be moved out of libsystemd and into a two-file (.h and .c) copylib?

A backdoor in xz

Posted Mar 31, 2024 12:17 UTC (Sun) by bluca (subscriber, #118303) [Link] (4 responses)

It used to be, but it was merged, because it's just an unnecessary pain for developers to have to know multiple extremely similar libraries, and have to reason about which one to use and link to, etc etc.

The manager <-> service protocol is trivial, so the solution is to just reimplement it if that's all you need. I'll check whether we have some MIT-0 copy-paste ready examples, and if not add it to the documentation.

A backdoor in xz

Posted Apr 1, 2024 5:31 UTC (Mon) by mchapman (subscriber, #66589) [Link] (3 responses)

systemd used to provide a reference implementation (+ header). Perhaps something like this could be brought back?

A backdoor in xz

Posted Apr 1, 2024 11:02 UTC (Mon) by bluca (subscriber, #118303) [Link] (2 responses)

There will be a MIT-0 (so it can be copy/pasted with impunity) self-contained example in the documentation where the protocol is defined

A backdoor in xz

Posted Apr 2, 2024 17:16 UTC (Tue) by bluca (subscriber, #118303) [Link]

This is now published: https://www.freedesktop.org/software/systemd/man/devel/sd...

A backdoor in xz

Posted Apr 2, 2024 20:40 UTC (Tue) by himi (subscriber, #340) [Link]

A similar reference implementation in a few other common languages would be nice, too - with systemd it's gotten so easy to write system daemons in things like python that a copyable reference implementation would be quite helpful. It's simple enough that no one's bothered writing a library, but fiddly enough to do properly that rolling your own isn't always the best option.

A backdoor in xz

Posted Mar 30, 2024 17:21 UTC (Sat) by nix (subscriber, #2304) [Link] (2 responses)

Journal files and coredumps really are a case where zstd would be a better choice than lzma: it's nearly as good compression-wise but compression is *much* faster, and both journals and coredumps are compressed much more often than they're uncompressed. (For things like .xz distro artifacts this is the other way around, so spending loads of time for slightly better compression is often a good idea -- or would be if xz wasn't also much slower and more memory-hungry than zstd at decompressing!)

A backdoor in xz

Posted Mar 31, 2024 12:19 UTC (Sun) by bluca (subscriber, #118303) [Link] (1 responses)

xz, gz and std are all supported, with a compile-time option to choose which one to use.

A backdoor in xz

Posted Mar 31, 2024 13:54 UTC (Sun) by nix (subscriber, #2304) [Link]

In hindsight, of course they are! I should have checked. (I'm even using zstd on my own system, but of course I forgot. I, uh, blame the clocks changing. ... what do you mean they only changed after I made that comment?)

A backdoor in xz

Posted Mar 30, 2024 21:49 UTC (Sat) by MarcB (guest, #101804) [Link]

This looks like a major improvement, at the very least, the spill-over into other process address spaces will be prevented.

Let's hope distributions follow up on this and reduce the set of essential packages.