Re: [PATCH 0/3] Implement LANDLOCK_RESTRICT_SELF_NNP_ON_EXEC

On Thu, 09 Jul 2026 at 12:09:25 +0200, Mickaël Salaün wrote:
> On Wed, Jul 08, 2026 at 09:39:24AM -0400, Justin Suess wrote:
> > Consider a sandbox launcher that depends on a set-user-ID helper, such
> > as launching applications through bubblewrap on distributions where
> > unprivileged user namespaces are disabled and bwrap is installed
> > set-user-ID root.

It's perhaps worth noting that the current version 0.11.2 of bubblewrap
deprecates this mode of use (it will refuse to run while setuid unless
that was explicitly enabled at compile-time), and the next release 0.12.0
will also remove the ability to enable it at compile-time.

When bubblewrap was first written, having it be setuid was a necessary
workaround for kernels/distros not letting it do its sandboxing job any
other way; but now that unprivileged user namespaces are more widespread,
its maintainers have come to the conclusion that when it's setuid,
the risk of vulnerabilities that allow a root privilege escalation
(CVE-2020-5291, CVE-2026-41163) is unacceptably high, so being able to
make it setuid is no longer a good trade-off.

> > This flag also closes a gap for CAP_SYS_ADMIN callers of
> > landlock_restrict_self(2) itself.  The no_new_privs/CAP_SYS_ADMIN
> > requirement exists to keep set-user-ID programs from running confused
> > inside a sandbox they do not expect.  However, a privileged process
> > that enforces a domain without setting no_new_privs leaves that hole
> > open for all of its descendants
> 
> In a nutshell, not setting NNP might be risky, even when not strictly
> needed.  We might want to update the Landlock doc with that.

If the CAP_SYS_ADMIN caller is setuid or setcap, then it has been
granted special privileges by the sysadmin or distro, and part of
the "contract" between the sysadmin/distro and the setuid program is
that setuid/setcap must only be set on executables that have taken
responsibility for ensuring that they can't create insecure situations
(for example bubblewrap always sets PR_SET_NO_NEW_PRIVS, unconditionally,
for this reason).

A large part of why bubblewrap no longer supports being setuid is that
its maintainers don't want it to have this heavy responsibility.

    smcv