Zbigniew Jędrzejewski-Szmek

The mkosi-initrd project builds initrds directly from system packages. This means that there is no separate dependency and packaging system. Normal system packages and services are used in the initrd. This means that we don't need to build a duplicate set of scripts. Systemd is used to the maximum extent — it sets up the environment and manages jobs in the initrd. Requirements and dependencies for startup tasks must be expressed as unit properties. Systemd's functionality is used to manage secrets, measure state, and load system extensions to extend the initrd. In this talk I'll cover the current state of the project (what works) and the plans for the future.

Systemd provides a bunch of features which can be used to contain and secure services, making security and isolation primitives provided by the kernel accessible to system programs. This allows service authors to write much simpler code, and often to avoid any integration with the operating system for security purposes. Unfortunately, those features are still not widely used, possibly because developers want to maintain compatibility with a wide range of systems.

I'll talk about the features that are the most useful, how they can be used in practice, and how this could be used to make a noticeable change in security at the distribution level.

The number of security features that systemd provides is long and growing: First, it performs setup like creating runtime directories and opening sockets, so the service doesn't need privileges. Second, it makes it easy to run services as unprivileged users, removing a whole set of problems. Third, it uses kernel features like mount and network namespaces, capabilities, resource limits, to constrain services. Fourth, it implements additional filters using BPF (per-service firewalls, devices controller). Fifth, it does resource cleanup after the service is done, removing the need for privileges again.

We could use this to vastly simplify services and to provide an additional level of security for system services. Some distributions are making use of this, but not nearly enough. Fedora is probably at the forefront, but the common case is still to run as root will full access to everything the service doesn't need. Debian is now discussing a General Resolution to drop SysV Init compatibility and empower packagers to use all systemd features. Full support in the two biggest distro families would motivate upstreams to make systemd their "baseline" and build more secure services. New features like "dynamic users" could be used to make Linux systems take more modern approaches to system security.

I want the talk to serve as a prompt for a general discussion how we could modernize service packaging in distros, to avoid reimplementing security features in individual daemons, and how to stop the 90's mentality of running everything as root.