Notices by Lennart Poettering (pid_eins@mastodon.social), page 3

…it is is "democratic", in the sense that anyone can do this without having to get their keys into some centralized keyring.

Hence, to me it implications of SB are simply not worth it, it brings very little to the table security wise, but creates massive headaches on deployment. MB otoh actually provides a high level of security, and you don't have to ask anyone to put together your own policies.

Hence if you ask me: focus on making MB a thing on Linux, and bother with SB only to the level…

Much more interesting is Measured Boot when tying disk encryption to it. Various OSes, including Windows have been supporting this since about forever. And it's so much better: it basically makes no restrictions on what you can run on your PC. All it enforces is: my encrypted disk can only be decrypted if the OS of my choice is booted in the version of my choice. And that's a *way* more powerful concept, because it is *focussed* on your installation, because…

One beef I have with GNU/FSF folks btw, is that they started that abominable campaign against TPMs back in the day, completely misunderstanding that TPMs are kinda the "democratic" thing, and if anything they should have criticized SecureBoot, but not TPMs.

So, if you ask me what my takeaway from the Crowdstrike issue is, I'd say: boot counting/boot assessment/automatic fallback should really be a MUST for today's systems. *Before* you invoke your first kernel you need have tracking of boot attempts and a logic for falling back to older versions automatically. It's a major shortcoming that this is not default behaviour of today's distros, in particular commercial ones.

Of course systemd has supported this for a long time:

https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/

As I understand the BSOD today became more popular than ever, truly becoming mainstream and reported about all over the news. Of course, in systemd we are ahead of the curve, as usual, and if you too want to experience your very own BSOD we have your back. Enjoy:

https://www.freedesktop.org/software/systemd/man/latest/systemd-bsod.service.html

Finally no need to feel left out again, just because you use Linux! 💖💘💝

Of course, everyone's favourite tool to build secure Linux images with dm-verity, TPM, SecureBoot is mkosi by @daandemeyer and others. It now is learning a new trick: support for AzureLinux (ex CBL Mariner) – in addition to the other 12 supported distributions.

And that's really great, because this means I can finally quickly test the stuff I am working on within the systemd project on my own company's Linux distribution, the same way I test other distributions.

Yay!

https://github.com/systemd/mkosi/pull/2833

REMINDER! All Systems Go! 2024 CfP ends TODAY! Don't forget to submit your proposal NOW!

→ https://cfp.all-systems-go.io/all-systems-go-2024/cfp

See you in Berlin!

@jmorris @GabrielKerneis I guess libselinux could find ways to avoid ELF constructros/destructors. For example initialize what they want to initialize lazily (i.e. when the first function that needs it is called), and then provide explicit functions that initialize/destroy what they want to destroy at the end. For systemd's use that would be enough.

I mean, i generally think libraries that have a lot of global state are a bit icky, but i guess that ship has sailed for libselinux…

Which means that constructors are invoked in the order the shared libraries are loaded in, and if shared libraries have dependencies, they are first loaded "down the tree". But that sucks hard, because libraries tend to have interdependencies, non obvious ones at that, and cyclic ones too! And that means you might end up calling functions from libs whose constructors haven't run yet, or whose destructors already ran.

Then, various libraries (including systemd's) use "-z nodelete", …

…, labelled, initialized and so on. One prominent library which we do link against that used to do horrible shit like that, is libselinux btw. They fixed much of it, but still use ELF constructors/destructors these days, and they really shouldn't.

Now you might say that not all projects are systemd, that we are a special case, but there are many other problems with it:

There's no ordering defined in which constructors/destructors are called. Or at least not a useful one: it's "topoligical".

Relevant C projects nowadays tend to have CI systems that run everything in their codebase through valgrind and memory sanitizers provided by the various compiler suites. This is an additional headache when ELF destructors are used: whether memory is leaked or not cannot be determined correctly from inside a process if you basically have to exit first to get the resources are actually released by the ELF destructor.

And then, various projects tend to open/close fds in their ELF…

… or are loaded via RTLD_NODELETE (for various reasons). The effect of that: the ELF destructors they provide will never be called, and what's worse, the destructors of any depending lib will never be called either, ever).

What's worse: it's not clear which thread invokes the constructors/destructors even. It might be the main thread, or some other thread, because dlopen() is used from it, directly or indirectly. And other code might run in parallel with your constructor/destructor hence.

… when the destroy function for the relevant contexts is called again.

And that's really all I'd ask for. This is great, because it means consuming code can carefully schedule when and in which context it wants to start making use of the library, and thus when it shall be initialized, and when it doesn't need it anymore, and when it shall be deinitialized again.

But enough of the expletives, let's talk a bit of what to do instead?

I think good C library design is always built around some kind of opaque context object (possibly multiple), that all relevant functions provided by the library get passed in as first argument. This context object should be allocated by one library function and destroyed by another, but key really is that the library is "dormant" until that constructor is explicitly called by its user, and "dormant" again…

… but let's stop this for now (there's more, really, for example sandboxing, and ELF const/dest really make an awful combo; or blocking syscalls in them will make dlopen() hang, or fricking locking in them is a desaster), and summarize:

ELF constructors/destructors run at the worst times, are not reasonably schedulable, run from arbitrary contexts, in abitrary threads, too early, and too late, maybe not at all, and not intstrumentable reasonably for analyzers. Hence, fuck them.

…constructors. But that sucks hard, because in so many cases system level C code must be able to ensure that all fds are closed (for example, in systemd we require this when we load MAC policy, so that all fds are definitely labelled properly, and for many other reasons) at some time, but if "hidden" fds are kept open, that cannot be reasonably closed unless a library is unloaded then things are just unworkable.

Anyway, there are other reasons ELF constructors/destructors are shit, …

@GabrielKerneis they probably just don't.

libselinux is a really bad offender not just regarding this red flag. I guess the reason they get away with it, is because they come from a time where CIs/test suites were not a thing yet, and they are so low level in our dep tree, that everyone just accepts their fate and ignores the red flags.

placement of too much state in global variables or TLS (instead of maintaining clean context objects), obvious TTOCTTOU races around file use, open coded structures, absence of symbol prefixing and so on.

But there's one red flag that I want to write about today, that's just so annoying, because it's not widely understood to be the devil's work: use of ELF constructurs/destructors.

In ELF/gcc you can mark functions as ELF constructurs or destructors. Functions marked like that…

When systemd's main() function is started it then goes through a careful process of setting things up, i.e. establishing mounts, making things writable, loading security policies, initializing certain devices, RNGs, and so on, loading configuration and many many other things. This is carefully scheduled to be done in the right order, since after all we cannot assume that things are already set up for us, we have to do the setup *ourselves* after all.

But of course (I guess like various C++ feaures), it's also terrible if people actually start using this IRL. In particular in systemd this is has brought a repeating theme of breakage to us.

The systemd service manager (aka "PID 1") runs very early at boot, it is after all typically the first userspace process invoked on a system. This means it initially runs in a very minimal execution context, for example /proc/ and /sys/ are typically not mounted yet, there's no /tmp/, and nothing else.