pid_eins

pid_eins, 2 days ago

And yes I am pretty sure they should revert the kernel change. Departing needlessly from the option name the other file systems give this is already wrong. But breaking all current systemd versions on new kernels just for the fun of it is extra wrong.

Note that I actually do think it's ok if kernel folks break interfaces every now and then if done for a good reason and if userspace is prepared. But here neither is the case. And my main beef here is that they claim they wouldnt do it ever...

pid_eins, 3 days ago

@hyc @wednesday well, any compiler used on any Linux from the last decade or more supports the cleanup stuff. And that pretty much matches systemd's intended audience.

pid_eins, 4 days ago (edited 4 days ago)

systemd is often used in smaller environments, i.e run in containers, or in the initrd or similar. Hence a large dependency tree is problematic.

Because of that in systemd we started to turn a large number of our dependencies from regular ones to dlopen() ones: instead of always requiring some shared library we only load it the moment we need it. This means we can gracefully degrade our feature set if certain libraries are not available.

pid_eins, 4 days ago

We have been doing this since quite a while, so that in v256 22 of our dependencies have been reworked like that.

This has the benefit that on a typical system the systemd binary itself only pulls in the C library (including libm), libmount, libselinux, libaudit and libseccomp.

Net result: we have a tiny required dependency footprint, but can still provide a large feature set, if the optional deps happen to be installed.

pid_eins, 4 days ago

This comes at a price though: since our library dependencies are now dlopen() based they do not show up in the ELF metadata of our binaries anymore. And package managers such as dpkg/rpm generally look at that, and automatically translate those ELF dependencies into packaging dependencies.

Hence: at first glance, this means that we regress on this front: previously automatically determined dependencies have to be encoded manually again.

With v256 we are doing something about this.

pid_eins, 4 days ago (edited 4 days ago)

All our binaries now contain an ELF "note" describing these "weak" deps that can be processed in a similar way as regular ELF dependencies.

The format of these notes is described here:

https://github.com/systemd/systemd/blob/main/docs/ELF_DLOPEN_METADATA.md

There's now work ongoing to process this data automatically at rpm and dpkg build time, so that we get the best of both worlds: "weak" dependencies and proper metadata to declare them consistently.

pid_eins, 4 days ago

For now the spec sits in systemd's repository. We intend to add it to the uapi group's repository soon though, as this really is supposed to be something not only systemd provides, but any software that is in a similar situation and uses dlopen() to gracefully import a fixed set of external libraries.

And that's all for now. Stay tuned for episode 16 soon.

(Sorry for not keeping up the pace btw, currently at a conference)

pid_eins, 5 days ago

@jarkko @kernellogger @jejb systemd's disk encryption stuff actually has been using encrypted sessions for a long long time.

pid_eins, 6 days ago

This of course makes the tool a bit more comfortable to use, since you don't have to figure out the backing block device of your encrypted volume first. But it's actually a security measure too:

On Linux referencing block devices by their device names such as "/dev/sda" is a bit problematic when it comes to security, since these names are reused on unplug/replug. Thus, there's a good chance that various security-relevant operations executed on disks can be tricked, …

pid_eins, 6 days ago

… by quickly removing one disk, and plugging in another, so that the device node goes away, and comes back under the same name, but suddenly referring to a different device.

There has been work on addressing this problem, specfically there's now a "diskseq" counter exposed on Linux block devices that changes on every media change and device unplug. Thus, if on first use of a device the diskseq number is stored away, and then verified on each subsequent operation it's possible to…

pid_eins, 6 days ago

… detect such tricks, and refuse operation. In systemd we thus started to make more and more use of diskseq, for example via /dev/disk/by-diskseq/ device symlinks, or by referencing block devices via their diskseq numbers whenever possible. This works is incomplete currently, there are gaps at various places (for example, there's no userspace API to query the diskseq number from a mounted file system that is backed by a block device).

pid_eins, 6 days ago

By automatically detecting the right block device the attack window for enrollment operations becomes a lot smaller, and once the last gaps in the diskseq kernel apis are fixed we can fully lock down things so that we can guarantee that it's really the right device we operate on and not some trick device.

You might wonder why we are derive the backing device of /var/ rather than the root file system for this automatic mechanism: that's because we generally focus on two ways to set up a system:

pid_eins, 6 days ago

1. you have a fully encrypted root fs, with /var/ being placed on the root fs too
2. you have an immutable root fs, but /var/ is mounted writable.

In both these cases using /var/ as the path to search the backing block device for will work, while using / instead would not work for the 2nd case.

Also note, that this mechanism is automatically disabled when a destructive operation is used (i.e. an existing key slot shall be wiped), for robustness reasons.

pid_eins, 6 days ago

And that's all for now, stay tuned for episode 15 soon.

pid_eins, 6 days ago

@marie indeed! fixed!

pid_eins, 6 days ago

@neingeist indeed! fixed!