Upcoming change notification for user units: PrivateUsers= to be implicitly enabled when sandboxing options are specified

[Luca Boccassi <bluca@xxxxxxxxxx>]

Hi,

This is an advanced notification for an upcoming behaviour change
being considered w.r.t. user units and sandboxing options.

User units (those run by the per-user session manager) and system
units share the same configuration options. But due to differences in
privileges between the user manager and the system manager (ie: PID1)
the behaviour with sandboxing options (i.e.:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html )
is different and a constant source of confusion for users, which has
been hampering the adoption of those security features.
Given most of those sandboxing options (e.g.: PrivateTmp=,
ProtectSystem=, etc.) require creating new mounts, and creating new
mounts requires privileges, they are silently skipped in user units.
It is trivial to make them work by also enabling user namespaces
(i.e.: PrivateUsers=yes), but it is not very well known and it is not
required by system units given PID1 is privileged, so it is almost
never done.

We want to change this, to streamline the experience and solve this
common source of confusion, to allow sandboxing options, which have
great security benefits, to be more widely used in the simplest way
possible.
The drawback is that user namespaces imply that system users are no
longer visible to the unit, only the user under which the user session
is run is. Given by definition these are unprivileged units run by an
unprivileged single user, the impact in practice should be minimal.

So starting from a future version (TBD) next year, we want to
implicitly enable PrivateUsers=yes for user units when a sandboxing
option that relies on new mounts is configured in the unit.
We did some research, and over the complete set of user units shipped
by Debian, Ubuntu and Fedora (about 350 units), only 6 enabled
sandboxing options (that were silently skipped), and all of them have
been fixed upstream to either drop the no-op settings or manually
enable PrivateUsers to make them work. This gives us a degree of
confidence that impact will be small enough to be worth the overall
benefits.

Note that in case unprivileged user namespaces are not available (very
old kernel, or manually disabled sysctl on a given system), then this
change will be a no-op, and everything will continue to (not) work
exactly as it did before.

If anybody is aware of any project shipping user units _with_
sandboxing options enabled and _without_ PrivateUsers=yes please let
us know, or better yet report it to the respective project so that it
can be fixed one way or the other (drop the ineffective option or
manually set PrivateUsers). Also let us know if there are other
negative impacts that we have not foreseen.

The PR that implements this change can be found at:
https://github.com/systemd/systemd/pull/25233

Kind regards,
Luca Boccassi