4 ms·

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

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.

Pyxl101 10y ago
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...
wmf 10y ago
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.

Pyxl101 10y ago

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

wmf 10y ago

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.