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

@duxsco my own focus with systemd is definitely on providing generic components that help make any Linux based systems more secure. hence, I do care a lot about solutions that provide security and can be deployed on *generic* systems in the wild, without prior knowledge of what they provide or not. It's the "general population", or the broader IT ecosystem I care about, not some nerdy niche.

@mjg59 on my windows laptop here bitlocker locks to 0, 2, 4, 8, 9, 10, 11. Which I think is today's default on modern Windows. (I certainly didn't change it). PCR 7 is not included interestingly.

And I think the TPM stuff in windows pretty much works, no?

systemd-pcrlock tries to lock to even more PCRs by default (but might exclude some if there are measurements we don't recognize).

@awilfox some other comments:

we actually want to get rid of basename() use, and converted most uses over to our own path_extract_filename() (which is a bit more careful with the corner cases, and returns proper errors). If you port over the rest, we'd happily merge that and your basename incompat goes away.

@awilfox do i read properly from this that musl defines HOST_NAME_MAX to something other than 64? that's pretty broken, given that the kernel internally defines __NEW_UTS_LEN to 64, and thus that's the limit sethostname() is going to accept...

@awilfox the utmpx.h inclusion is upstreamable. we generally use the utmpx interfaces, since they appear to be the more modern ones. if some holdout code still uses utmp.h that should be fixed.

@awilfox Regarding split /usr/? What is this? 1999? All big distros have cleaned this up, which distros is this that still parties like it's 1999?

@awilfox your strerror_r() hack is not thread safe...

@awilfox i hope musl is not something people use for smaller/embedded/resource constrained system given it appears not to have a memory compaction (malloc_trim()) api? what is musl for then? kinda confused by that tbh, because i though that's what people use musl for?

Noone asked me, but if you are curious what my take on the recent sbat/SecureBoot kerfuffle is, I'll let you know anyway:

Frankly, I find SecureBoot ultimately pretty uninteresting tech. It casts a very wide net: it basically is a politically charged global allowlist, yet is useful as a very very lose denylist only, because it necessarily contains so so so much stuff. I think the value for security is relatively limited, because it it attempts to be universal, and hence can never be focussed.

…you really have to.

(I am trying to do my part on this of course, i.e. in systemd we measure a lot of things during boot now, and our FDE logic is hooked up with it.)

[That all said, I think SB might have some value if you enroll your own keys, which however can only work on very specific hw, and in VMs, but is probably not a solution realistic for general purpose PCs]

…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".