
New sandbox features in systemd - okket
https://endocode.com/blog/2016/11/04/new-sandbox-features-in-systemd/
======
mixedCase
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?

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

~~~
mixedCase
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
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...](https://www.freedesktop.org/software/systemd/man/systemd-
nspawn.html#--private-users=)

------
oridecon
[https://lists.freedesktop.org/archives/systemd-
devel/2016-No...](https://lists.freedesktop.org/archives/systemd-
devel/2016-November/037698.html)

