Those sandboxing solutions are toolkits that help you employ Linux kernel APIs to achieve a desired configuration. The Linux kernel is the underlying sandboxing

Those sandboxing solutions are toolkits that help you employ Linux kernel APIs to achieve a desired configuration. The Linux kernel is the underlying sandboxing API, and Docker and rkt and systemd all expose its features in different ways. For example, if you launch a container with Docker, then you might tell it to employ user namespaces as a way of isolating processes within the container from the rest of the system. This helps ensure that "root" inside the container is not really "root" outside it, and that the "nobody" user in two different containers is not actually the same user. Systemd also gives users the ability to employ user namespaces (and other kernel features) while launching services, in this case through the --private-users flag to systemd-nspawn [1]. The article we're discussing does not describe a new systemd component, but a new set of configuration parameters for employing, in user space, some features offered by the Linux kernel. One of the new parameters is ProtectSystem=strict which launches processes with a read-only view of the file system. It's valuable for systemd to support these facilities directly and not punt the problem to a higher level. To summarize, since systemd is the init system, exposing these features in systemd means that Linux kernel namespacing features can be employed even with very low-level system services; and they can be employed in configuration by administrators even with services that don't know how to self-sandbox to the same degree. [1] https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--private-users= https://www.freedesktop.org/software/systemd/man/systemd-nsp...