@pid_eins@mastodon.social
@pid_eins@mastodon.social avatar

pid_eins

@pid_eins@mastodon.social

⛵ I write software. ⛵

This profile is from a federated server and may be incomplete. Browse more on the original instance.

pid_eins, to random
@pid_eins@mastodon.social avatar

When pondering whether we should start linking to some external library in systemd, I usually spend some time looking at the library's sources, to understand the quality of the code. While coding style differences are fine, there are certain red flags that make libraries unsuitable for use in systemd, or that indicate questionable quality of the code.

Red flags like this are for example absence of OOM guards on malloc(), absence of reasonable error propagation,

pid_eins,
@pid_eins@mastodon.social avatar

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…

pid_eins, to random
@pid_eins@mastodon.social avatar

Kernel breaking userspace episode nr. 43858262:

https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66

Hacking around it:

https://github.com/systemd/systemd/pull/32892

pid_eins,
@pid_eins@mastodon.social avatar

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, to random
@pid_eins@mastodon.social avatar

1️⃣5️⃣ Here's the 15th installment of posts highlighting key new features of the upcoming v256 release of systemd.

systemd integrates with many components of the OS. Due to this it links against various external libraries. Generic distributions – which typically enable all features a package provides – usually have to deal with relatively large dependency trees in cases like this.

pid_eins,
@pid_eins@mastodon.social avatar

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, (edited )
@pid_eins@mastodon.social avatar

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, to random
@pid_eins@mastodon.social avatar

1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd.

ssh is widely established as the mechanism for controlling Linux systems remotely, both interactively and with automated tools. It not only provides means for secure authentication and communication for a tty/shell, but also does this for file transfers (sftp), and IPC communication (D-Bus or Varlink).

pid_eins,
@pid_eins@mastodon.social avatar

And ssh-via-AF_VSOCK is precisely what we are doing in systemd v256: a small new unit generator (i.e. a plugin that extends systemd's unit tree dynamically) detects if AF_VSOCK is available and sshd is installed, and if so binds AF_VSOCK/port 22 to sshd, via socket activation. Or in other words: in environments where AF_VSOCK is a thing, sshd will now just work, without any extra configuration and at minimal cost of resources (because lazy socket activation rocks).

pid_eins, to random
@pid_eins@mastodon.social avatar

7️⃣ Here's the 7th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

In systemd we put a lot of focus on operating with disk images, specifically file system images that carry an expressive GPT partition table – something that we call DDIs ("Discoverable Disk Images").

pid_eins,
@pid_eins@mastodon.social avatar

Various tools (including: systemd-nspawn, systemd-dissect, RootImage= in service files) have been updated to make use of this new IPC service, and thus can now operate without privileges. Or in other words: there's now unprivileged systems-npsawn containers. Yay!)

And that's all for today. See you soon for the 8th installment of this series.

pid_eins, to random
@pid_eins@mastodon.social avatar

6️⃣ Here's the 6th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

In the 2nd installment of this series we have already discussed system and service credentials in systemd a bit. Quick recap: these are smallish blobs of data that can be passed into a service in a secure way, to parameterize, configure it, and in particular to pass secrets to it (passwords, PINs, private keys, …).

pid_eins,
@pid_eins@mastodon.social avatar

Environment variables after all suck for passing secrets, since they are by default inherited down the process tree, even across privilege changes, are placed in swappable memory, cannot be recalled, have no access control concept (i.e. not locked to the UID/GID) and so on.

There's one particularly nice facet of systemd's credentials concept: they are not just service credentials, but also system credentials.

pid_eins, to random
@pid_eins@mastodon.social avatar

5️⃣ Here's the 5th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

I am pretty sure all of you are well aware of the venerable "sudo" tool that is a key component of most Linux distributions since a long time. At the surface it's a tool that allows an unprivileged user to acquire privileges temporarily, from within their existing login sessions, for just one command, or maybe for a subshell.

"sudo" is very very useful, as it…

pid_eins,
@pid_eins@mastodon.social avatar

… manual clean-up is just not how security engineering should be done in 2024 anymore.

With systemd v256 we are going one step towards this. There's a new tool in systemd, called "run0". Or actually, it's not a new tool, it's actually the long existing tool "systemd-run", but when invoked under the "run0" name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it's not in fact SUID. Instead it just asks the service manager to invoke a command or shell under…

pid_eins,
@pid_eins@mastodon.social avatar

… enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that.

So, in my ideal world, we'd have an OS entirely without SUID. Let's throw out the concept of SUID on the dump of UNIX' bad ideas. An execution context for privileged code that is half under the control of unprivileged code and that needs careful, …

pid_eins,
@pid_eins@mastodon.social avatar

… the target user's UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY.

Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).

One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways. Except that…

pid_eins, to random
@pid_eins@mastodon.social avatar

A while back we started to turn many of the library dependencies of systemd from regular ELF dependencies (which you can explore with tools like lddtree or readelf -d … | grep NEEDED) into dlopen() deps, in order to minimize the dep footprint of systemd. The primary reason for this was to make it easier to build small disk images without optional components, in particular for the purpose of initrds or container deployments. Recently, another reason for doing this came into focus:

pid_eins,
@pid_eins@mastodon.social avatar

… expose these kinds of deps really nicely in their packaging metadata, if they just knew about them.

Hence, if the lack of dep metadata is the main big con of dlopen() deps, let's see if we can do something about it!

here's my proposal about this: https://github.com/systemd/systemd/pull/32234

It's a very simple approach. All it does is insert an ELF "note" into generated binaries that declare these deps. This information can then be consumed by package managers, initrd generators and other tools.

pid_eins, to random
@pid_eins@mastodon.social avatar

PSA: In context of the xzpocalypse we now added an example reimplementation of sd_notify() to our man page:

https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes

It's pretty comprehensive (i.e. uses it for reload notification too), but still relatively short.

In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial

pid_eins,
@pid_eins@mastodon.social avatar

that one can explain it in one sentence: send an AF_UNIX datagram containing READY=1 to a socket whose path you find in the $NOTIFY_SOCKET env var.

But apparently turning that sentence (which appears in similar fashion in the man page) into code is not trivial, hence this new example code.

Hence, copy away, the thing is MIT licensed. And the protocol has been stable for a decade, and I am pretty sure it's going to remain stable for another decade at least.

siosm, to fedora
@siosm@floss.social avatar

sudo without a setuid binary or SSH over a UNIX socket: https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/

I have been working on this setup as part of my investigation to reduce our reliance on setuid binaries and trying to figure out alternative for common use cases.

pid_eins,
@pid_eins@mastodon.social avatar

@siosm On a more positive note: we'll soon have fully rootless nspawn. Without setuid mess. See this:

https://github.com/systemd/systemd/pull/26826

pid_eins, to random
@pid_eins@mastodon.social avatar

The excellent CCC VOC people published the AllSystemsGo! videos from this week. Here's the UKI talk I did there:

https://media.ccc.de/v/all-systems-go-2023-185-unified-kernel-images-ukis-

Enjoy!

pid_eins, to random
@pid_eins@mastodon.social avatar

Busy at the Image-Based Linux Summit, Berlin!

pid_eins, to random
@pid_eins@mastodon.social avatar

Can't wait for Wednesday, for AllSystemsGo! 2023. So many exciting talks! Have a peek at the schedule:

https://cfp.all-systems-go.io/all-systems-go-2023/schedule/

pid_eins, to random
@pid_eins@mastodon.social avatar

Exciting: → https://blogs.gnome.org/alatiera/2023/08/04/developing-gnome-os-systemd-sysext/

pid_eins, to random
@pid_eins@mastodon.social avatar

Quick! Only three more days, and the All Systems Go! 2023 CfP ends! Submit now! https://cfp.all-systems-go.io/all-systems-go-2023/cfp ← ⚡️🏃🏻💨💨

pid_eins, to random
@pid_eins@mastodon.social avatar

Pssst! 🤫 We have an impressive systemd release v254 coming up soon! If you are curious, have a look at what's cooking here, but don't tell anyone just yet: https://raw.githubusercontent.com/systemd/systemd/main/NEWS (We hope to tag rc1 next week or the week after)

pid_eins, to random
@pid_eins@mastodon.social avatar

The AllSystemsGo! 2023 CFP ends in ⏳ ~2 weeks ⏳. Make sure to submit your talk now! 🏃‍♂️🏃‍♂️🏃‍♂️🏃‍♂️ See you in Berlin! → https://all-systems-go.io/

pid_eins, to random
@pid_eins@mastodon.social avatar

interesting: https://fedoramagazine.org/use-systemd-cryptenroll-with-fido-u2f-or-tpm2-to-decrypt-your-disk/

pid_eins, to random
@pid_eins@mastodon.social avatar

@brauner and I did a talk about mounting disk images (i.e. block based file systems) in unprivileged code reasonably securely, back at LFSMMBPF in Vancouver, two weeks ago. A video of the session is now online: https://www.youtube.com/watch?v=RbMhupT3Dk4 – enjoy!

pid_eins, to random
@pid_eins@mastodon.social avatar

Here's a fun new feature we are working on in systemd: userspace-only reboot. In order to reduce grey-out times on image-based OS updates to next to nothing we are making a reboot happen where kernel stays as it is, but userspace shuts down as usual, then possibly transitions into a new rootfs, and starts up again with an initial transaction as it would on a classic system boot. During the transition selected services can pass along their fds and listening sockets, to pass "live" resources…

pid_eins, to random
@pid_eins@mastodon.social avatar

PSA: Thou shalt not write udev rules with ACTION="add|change". Thou shalt use ACTION!="remove" instead.

If you look for "positive" events (i.e. that the device is present when it happens) then this is what you have to do. Why does this matter? Various kernel subsystems nowadays issue additional action event types (bind, unbind, …) that fire as part of device bring-up (usb…), and if your rule doesn't match on those the effect of your rules will likely be undone as these new actions are fired.

pid_eins, to random
@pid_eins@mastodon.social avatar

Now to one of the big questions of our times: what's better style? open("…", O_DIRECTORY|O_RDONLY|O_CLOEXEC) or open("…", O_DIRECTORY|O_CLOEXEC)?

Of course, both are entirely equivalent, because O_RDONLY on Linux is 0. But on a philosophical, conceptual level, what's the better way to write this?

(Asking because half of the systemd codebase does it one way, the other does it the other way.)

This is your time to shine, and contribute to the major philosophical discussion of today!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • mdbf
  • ngwrru68w68
  • modclub
  • magazineikmin
  • thenastyranch
  • rosin
  • khanakhh
  • InstantRegret
  • Youngstown
  • slotface
  • Durango
  • kavyap
  • DreamBathrooms
  • megavids
  • GTA5RPClips
  • ethstaker
  • normalnudes
  • tester
  • osvaldo12
  • everett
  • cubers
  • tacticalgear
  • anitta
  • provamag3
  • Leos
  • cisconetworking
  • lostlight
  • All magazines
    •