@pid_eins@mastodon.social

@swick and it's really shameful that supposedly security minded programming language communities (rust...) don't grok that, and happily work with the guaranteed insecure traditinal posix stuff instead of doing things better. I am pretty sure posix fs shenanigans are a bigger attack surface these days to gain privs than frickin memory unsafety, and focussing solely on memory stuff ignoring the fs stuff is just bad security engineering.

29

8

9

3

Lennart Poettering @pid_eins@mastodon.social

· 3mo ago

2️⃣7️⃣ Here's the 27th post highlighting key new features of the recently released v261 release of systemd. #systemd261 #systemd

systemd-oomd is systemd's subsystem for optimizing system behaviour under memory pressure (i.e. shut down services to remedy memory pressure and similar). So far it has been applying very similar policies for dealing with pressure on all workload services on the system.

With v261 we are extending the concepts around this considerably. systemd-oomd can now read a number…

mastodon.social

12

1

5

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

I just finished my #systemd260 series of posts. And I now also prepped a blog story linking to every single one of them here:

https://0pointer.net/blog/mastodon-stories-for-systemd-v260.html

Make sure to stay tuned for the #systemd261 series, most likely starting already in a few weeks!

mastodon.social

34

0

12

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

Replying to

@swick it's amazing how broken and unsecure posix fs apis have been from day one and still are (i.e. there is no posix way to convert an O_PATH fd to a real one for regular files for example)... And really sad that even modern programming language standard libraries always focus on the posix fs api, mostly ignoring the new stuff, -- rather than focussing on the newer stuff and then trying to retrofit the old stuff to work like the new stuff wherever possible.

12

1

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

RE: @allsystemsgo@fosstodon.org

The best conference around, and this time with a heavy @amutable@mastodon.social presence!

fosstodon.org

11

2

4

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

@cas@social.treehouse.systems i am waiting for the moment when these folks who partake in this misguided shitstorm learn about the kind of PII the good old GECOS field on Linux/UNIX carries... And once people are over that the next shock waits for them! There's a file in /etc/ that contains a hash (i.e. a unique identifier!) of your most personal, private, secret data: your password. And linux systems even kinda insist on you on providing that on first install! Can you believe that?

13

7

6

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

@cas@social.treehouse.systems It's as if UNIX carries AN ENTIRE DATABASE of PII in /etc/ without any consideration for user's privacy! Unbelievable! I think we all need to *demand* from Kernighan and Ritchie to immediately drop /etc/passwd and related files from UNIX, and stop helping the government with collecting this kind of data. It's really appalling that no one has called them out on this yet! The shock! The horror!

12

19

2

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

…which is enough to run a full OS inside a system service. Yay! And not just that: it also works unprivileged, i.e. it's enough to also run a full OS with 64K UIDs from a user controlled directory tree. Yippieh yay!

11

2

3

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

The systemd-report tool is then supposed to compile a unified report from those metrics and these facts, optionally combine with a TPM quote + TPM event log extraction, and output the whole thing as a single object that now contains everything one might want to know about a specific node at a given time: the cryptographically protected measurements, the current resource use and behavior, and all kinds of other facts, all in a completely pluggable, extensible, generic way, with very lose coupling

12

0

3

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

…on /run/systemd/io.system.JournalAccess (access only for system users) or $XDG_RUNTIME_DIR/systemd/io.systemd.JournalAccess (only for regular users). It's not quite yet as powerful with the filtering options as journalctl invoked from the command line, but in the coming releases we hope to fill all the relevant gaps.

10

0

2

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

…use "kernel-install" and when use "bootctl link", I'd suggest: use kernel-install on traditional package-based distros, since installing a kernel there means doing a tonload of auxiliary work on various subsystems. Use "bootctl link" on modern image-based distros, where all that work is already baked into the update images themselves. "bootctl link" is symmetric to the pre-existing "bootctl unlink". The latter removes a Type #1 entry from the ESP, and understands a concept of GC: it…

5

2

1

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

…rigid in nature: only one allowed kernel command line. We eventually added the concept of "profiles" to UKIs, so tha a single UKI could synthesize multiple boot menu entries, which enables you to chose one of many pre-prepared kernel command lines. Which is much more powerful, but still a bit rigid: we needed ways to securely insert local parameterization into such a system (i.e. some signature keys or so, machine identity, …) so we added the concept of "side cars" to the thing, that…

5

2

1

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

The last remaining step, i.e. #2 I am currently working on. Once that's in place an interactive OS installer could then just install an OS very cleanly, very robustly, and very quickly via 4 Varlink IPC calls. Yay!

8

0

3

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

Besides implementing the metrics interface in more of the services systemd ships, we also are planning a number of other improvements in upcoming versions. For example, I plan to augment the metrics interface with a "facts" interface, that is structured similarly, but instead of retrieving time-series style data it retrieves "static" data about the system, that is worth reporting, such as identity, public key material and so on.

9

1

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

With v261 we are going full circle to some level: there's now a new command "bootctl link", which links together a UKI (aka a Type#2 entry) and a bunch of side-cars and generates a new Type #1 entry from it (or, possibly, multiple, if profiles are used). "bootctl link" hence plays a role somehwat similar to the pre-existing "kernel-install" tool, but has a much stricter focus: it does not support any plugins, but it does support Varlink from day 1. If you ask me when distros should…

4

2

1

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

…will iterate through al referenced resources of an entry, and remove them if they are no longer referenced by any other Type #1. The former installs a new entry into the ESP along with its resources, if they haven't been copied there yet. "bootctl link" also has a lot of really nice robustness properties: it carefully makes sure to place all resources into the ESP fully, before actually linking them into place. Thus, behaviour is somewhat atomic: either the entry fits in fully and all is…

4

2

1

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

…allow "enriching" a UKI via system credentials, sysext DDIs, confext DDIs or EFI addons. But this so far left one question unanswered: how do I generate a new menu entry from a sidecar + UKI combination of my choice? after all, the reason we even support multiple menu entries is to support multiple versions of the kernel, so that one can always fall back. But this kind of fall back logic should also apply to the sidecars, because they have a chance to fail as much as the kernel itself has.

4

2

1

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

…API for it. This is useful as a backend for OS installers.

To provide a bigger picture: in my view of the world an OS installer does four things:

Stream in a /usr/ tree and very few auxiliary partitions via systemd-repart
Install a suitable UKI kernel image in the ESP or XBOOTLDR
Install systemd-boot as boot loader in the ESP
Configure a few basic parameters for the new installation via systemd-creds.

Of these 4 steps, #1, #3 and #4 now are accessible via nice Varlink APIs.

7

1

2

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

This feature is lovely, because it unblocks nested containers: you can put unpriv nspawn in unpriv nspawn and it will work reasonably, with privilege separation and everything.

7

0

1

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

@cas@social.treehouse.systems right after installing CrazyOS I'll make a video of it and put it on TikTok, YouTube and Instagram of course (I really dig their services, I have accounts everywhere, ha!). Hey, did you hear the web folks have cookies! 🍪 Yummy! So good!

7

4

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

@daandemeyer You forgot to mention that this functionality is in particular useful in secure environments, since it allows serial console handling without breaking the secure boot chain, i.e. because sd-stub appends it on its own based on trusted info, we don't have to measure it explicitly, and thus switching to booting via serial doesn't break measurements that shouldn't really be broken. Or in other words: this is not just handy, but load bearing.

6

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

…and unify currently distinct but similar codepaths in systemd's service management and systemd-nspawn's codebase. With v260 we filled in one major gap to get there: the existing PrivateUsers= setting for services now supports a new value "managed". If selected then a new delegated user namespace UID range is allocated dynamically via systemd-nsresourced, and assigned to the service. Or in other words: there's now a way to spawn a service with a full set of private, transient, 64K UIDs…

6

2

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

Replying to

@zeenix sorry, but you are basically saying that using rust for system level software where security boundaries exist is not really an issue because it isn't the intended audience for rust, and just too specific. I am pretty sure you are pretty alone in that view of the world though... FS access is a commodity, it just has to be there, hast to work, and be as secure as possible by default because it's highly security relevant, and a primary security boundary itself. Just accept that please.

4

1

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

@cas@social.treehouse.systems i never trusted these people in the first place and boy was I right. I'll now move one of my machines to CrazyOS because it stores no PII at all. That will hurt Kernighan and Ritchie, Ha! CrazyOS will not store *any* PII, it's so good! It doesnt have a password (MS-DOS back in the day already had that, and it should be common sense), you just are let in right away. It's kinda annoying though that it has no $HOME to store data in, but of course that's cool, because that would be PII...

6

1

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

Replying to

@dvzrv oh god now you made me read the gnupg commits around systemd support. Jeezuz.

4

1

2

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

…status quo (under the assumption that it works, given we came far enough to run "bootctl link"), and all that in reasonably "atomic" fashion.

2

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

…available, instead of just giving up, it will automatically delete the oldest entry (using the aforementioned bootctl unlink GC logic), repeatedly until enough space is available. When doing this it will carefully protect the currently booted entry however. Each time it will then attempt a link operation again. In essence: the logic should be really robust and make the best of what's available: keep as many menu entries as possible, but avoid failures as long as possible, protecting the…

2

4

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

…good, or something fails (which typically means not enough disk space), and then nothing actually materializes in the ESP, and is removed already before it ever was linked in. Given that the ESP is VFAT there are limits to how "atomic" we can make that, but I think we should be pretty good in effect, as every call first cleans up what might be left (even if very unlikely) from the previous one. Moreover it comes with an unlink strategy built into the linking strategy: if disk space is not…

2

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

Replying to

@zeenix open claude, type in "Give me 10 recent cves where path traversal issues were the cause". Gives you 10 great examples, recent ones. Not that hard.

2

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

…the activation and mounting of disk images. It's not the only mechanism to lock things that got some love in systemd v260: /etc/crypttab (and equivalent ways to configure a LUKS volume, such as the kernel command line) acquired a new option: fixate-volume-key=. This per-volume option accepts a hash derived from the volume key of the LUKS volume. If specified, activation will only succeed if the volume key actually matches this hash. There's a counterpart to this in systemd-repart, …

3

2

1

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

Replying to

@Valentin@mastodon.social my guess is that seek times kill you. I think cdroms/dvds have random seek times of 200ms or even more on old drives, which is abysmal. If you actually care about this you could start reading linearly into memory. On a dvd that's like 1.5mb/s though, i.e. also pretty awful... I.e. 90mb/min. So for 3gb it's too slow. What people used to do is profile what is actually accessed during boot and then put this stuff at the beginning of the medium, and read that in linearly.

2

4

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

…i.e. systemd's disk image generator and dynamic partitioner, that can generate encrypted file systems. If the (pre-existing) --generate-crypttab= option is used it will now automatically write out the right fixate-volume-key= options, so that the crypttab and the disk image are tightly bound together.

2

0

1

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

Replying to

@josh @swick yeah, i don't buy into that race to the bottom thinking. Designing stuff with the shittiest model in mind instead of the best is just awful engineering. Always figure out where you want to be, i.e. go for the summit — and then fill in the gaps/degrade gracefully where you have to on worse systems. But that's really not what rust is doing there. It's letting itself be held hostage by the worst system, and let's that heavily leak into its APIs...

1

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

Replying to

@Valentin@mastodon.social 10min is kinda awful though. How large is the image?

1

2

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

@levitating those sound like missing features we should cover. can you file bugs about that? i'd rather fix --bind-user= and stuff for managed userns, than to put work in unmanaged userns

1

0

Lennart Poettering @pid_eins@mastodon.social

· 4mo ago

Replying to

@NekkoDroid@social.treehouse.systems "bootctl unlink" and "bootctl link" only operate on entries associated with the current image. They stack away from other installed images.

0

1

0

Lennart Poettering @pid_eins@mastodon.social

· 5mo ago

Replying to

@levitating not right now, no. System users (as created by systemd-sysusers) are generally understood to be placed in /etc/passwd still.

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

@vepr_jako_pepr@mastodon.social yeah, precisely, but why would you fill the birth date field then if you don't fill the gecos field either? You know, the PR we merged only adds a field where the birthday *could* be stored, if you supply it. But that's entirely optional, and you have to go out of your way to provide it actually...

0

1

0

Lennart Poettering @pid_eins@mastodon.social

· 6mo ago

Replying to

@levitating we kinda see the non-managed userns stuff as legacy, and want to get away from it. Where are you missing something in the managed stuff that the unmanaged stuff gave you

0

1

0