All Systems Go! 2025

Linux lacks a coherent security model, and by extension we never defined one for the systemd project either.

In this talk I'd like to start changing this, and begin defining some general security design guidelines that we so far mostly followed implicitly, and make them more explicit. After all, systemd to a large degree is involved in security subsystems, from SecureBoot, Measured Boot & TPM, to its service sandboxing, dm-verity/dm-crypt support, its FIDO2/PKCS#11 hookups, its many security boundaries, secure parameterization, Linux Security Module initialization and more.

While this distributions & applications consuming systemd might follow different security models I think it's important to talk about a unified vision from the systemd upstream perspective, even if various downstreams then make modifications or only deploy a subset of it.

Let's have an open discussion with systemd developers who are at ASG and users in the audience. We will open with the developers saying what they plan to work on in the near future, and then allow questions / comments from the audience.

Many traditional container engines make use of the "subuid" concept and the "newuidmap" tool to implement a concept of "unprivileged" user-namespace containers on Linux. This approach has many shortcomings in my PoV, from both a security and scalability standpoint.

Recent systemd versions provide a more powerful, more secure, mor scalable alternative, via systemd-nsresourced, systemd-mountfsd and other components.

In this talk I want to shed some light on the problems with the "old ways", and in particular focus on what the "new ways" bring to the table, and how to make use of them in container runtimes.