[PATCH 0/3] Implement LANDLOCK_RESTRICT_SELF_NNP_ON_EXEC

[Mickaël Salaün]

On Sat, Jul 11, 2026 at 01:00:20PM -0400, Justin Suess wrote:
> On Thu, Jul 09, 2026 at 12:22:40PM +0100, Simon McVittie wrote:
> > 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.
> >
> Understandable. I guess my usecase proposed was narrower than thought.
> And we probably want to avoid creating risky confused deputy scenarios.
> 
> So now I'm leaning towards the LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS path,
> dropping the "ON_EXEC" part as Mickaël proposed.
> 
> But I'm struggling to see where the value is added over the prctl call.
> Sure atomic enforcement with the ruleset is nice, but not a huge value added
> on it's own.
> 
> Perhaps the setting of this bit with a -1 ruleset_fd could enable auditing
> of the (failed or successful) privilege acquisition for the domain via the
> fcaps/suid/guid methods w/o setting NNP? (otherwise this would be no
> different from a Landlock specific prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
> call).
> 
> And setting it with a non -1 ruleset_fd would set NNP *and* enable the
> same auditing.

I guess in this context "auditing" means for the caller to know what is
the origin of the error?

> 
> That way we are making this a "value-added" flag instead of just a landlock-flavored
> prctl call.
> 
> This would work well with the LANDLOCK_PERM_CAPABILITY_USE proposal,
> which allows us to audit both methods of acquiring new capabilities.
> (the clone/unshare path, and the fcaps/setuid/setgid path).
> 
> What do you think Mickaël?

I wasn't sure if we should or not artificially restrict the use of this
new Landlock NNP flag.  Fundamentally, it is not tie to a ruleset,
and like LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF it could be used with
ruleset as -1.  However, I don't really see a use case where a program
would "just" drop NNP and would not be interested to create a (minimal)
sandbox with Landlock (e.g. at least the scope restrictions).

Anyway, LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF should remain an
exception (for a good reason), and any other use of -1 as ruleset should
be well justified.

BTW, if one day we need need to defer this NNP we should also add a new
dedicated flag for that, so it is not an issue.