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

[Luca Boccassi <bluca@xxxxxxxxxx>]

On Tue, 27 Dec 2022 at 11:15, Luca Boccassi <bluca@xxxxxxxxxx> wrote:
>
> 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

Following this notice, and then the notice in the release notes for
v253, this is now merged in main and will thus be part of v254.

Kind regards,
Luca Boccassi