Ok. I'll be that guy.

Is there a clear, stable interface to define this layer as a separate one from the rest of systemd which would also allow for a different implementation to be leveraged by the service manager; or is this just another tightly coupled component for systemd with no regard for anything or anyone else?

The article describes a number of parameters that can be used to control and sandboxes processes launched by systemd. One of those existing parameters is (e.g.) CapabilityBoundingSet= which allows you to configure (i.e. limit) the set of Linux capabilities that the process has. The article describes how the author's company has contributed a few new parameters like ProtectSystem=strict which gives the process a completely read-only view of the file system, and ProtectKernelModules=yes which prevents the process from loading kernel modules.

The underlying clear and stable interface used to accomplish these things is the Linux kernel, and another service manager could provide the same features. Systemd has a configuration file format for expressing how to launch processes (which is what I'm describing above). Another service manager could parse and understand that format, if it wanted, in the same way that systemd supports SysV init scripts and classic ways of managing service lifecycle like "service foo restart" alongside its new command systemctl.

Perhaps it depends whether you see sandboxing as a tool or as a feature. There is https://github.com/projectatomic/bubblewrap if you want sandboxing without systemd.

I think you guys have missed the point. I do know there are several sandboxing implementations for Linux, what I was "wondering" was wether systemd would offer an interface for these solutions to implement so that they can power systemd's sandboxing API rather than relying on yet another systemd component.

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-nsp...

systemd is never going to work that way and it sounds like maybe you already know that so it borders on trolling to bring it up. This functionality is pretty straightforward so I'm not sure what the value of multiple competing implementations would be.

You can do something like ExecStart=bubblewrap foo, but that's a different syntax than systemd's native sandboxing.