Re: [PATCH v3 3/4] landlock: Document LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS

["Mickaël Salaün" <mic@digikod.net>]

On Mon, Aug 03, 2026 at 06:31:07PM -0400, Justin Suess wrote:
> Document setting no_new_privs with ruleset enforcement, following the
> same compatibility section style as previous ABI additions.
> 
> Include a section explaining the tradeoffs of setting no_new_privs
> through any means for privileged users of Landlock.
> 
> Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> ---
> 
> Notes:
>     v2->v3:
>     - Update the tutorial: restrict_flags per ABI version and prctl call
>       skipped when LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS is used
>     - Drop "Atomic" from the section title; describe the ordering instead
>     - Explain that not setting no_new_privs is risky even when not required
>     - Fix ABI 8/9 switch coverage (case 8 ... 10) and indentation
> 
>  Documentation/userspace-api/landlock.rst | 47 +++++++++++++++++++++---
>  1 file changed, 41 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst
> index 5085822d8930..0e4a73fd5ea4 100644
> --- a/Documentation/userspace-api/landlock.rst
> +++ b/Documentation/userspace-api/landlock.rst
> @@ -8,7 +8,7 @@ Landlock: unprivileged access control
>  =====================================
>  
>  :Author: Mickaël Salaün
> -:Date: July 2026
> +:Date: August 2026
>  
>  The goal of Landlock is to enable restriction of ambient rights (e.g. global
>  filesystem or network access) for a set of processes.  Because Landlock
> @@ -250,7 +250,8 @@ similar backwards compatibility check is needed for the restrict flags
>  
>      __u32 restrict_flags =
>          LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
> -        LANDLOCK_RESTRICT_SELF_TSYNC;
> +        LANDLOCK_RESTRICT_SELF_TSYNC |
> +        LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS;
>      switch (abi) {
>      case 1 ... 6:
>          /* Removes logging flags for ABI < 7 */
> @@ -269,16 +270,36 @@ similar backwards compatibility check is needed for the restrict flags
>           * children (and not for all threads, including parents and siblings).
>           */
>          restrict_flags &= ~LANDLOCK_RESTRICT_SELF_TSYNC;
> +        __attribute__((fallthrough));
> +    case 8 ... 10:
> +        /* Removes no new privs flag for ABI < 11 */
> +        restrict_flags &= ~LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS;
>      }
>  
>  The next step is to restrict the current thread from gaining more privileges
> -(e.g. through a SUID binary).  We now have a ruleset with the first rule
> -allowing read and execute access to ``/usr`` while denying all other handled
> -accesses for the filesystem, and two more rules allowing DNS queries.
> +(e.g. through a SUID binary).  For unprivileged processes, setting the
> +no_new_privs attribute is required by Landlock.
> +
> +Processes with ``CAP_SYS_ADMIN`` in their namespace can enforce a ruleset
> +without it, but not setting no_new_privs is risky even when it is not

This is a new paragraph and understanding the "it" requires some
stretches.

> +required: sandboxed processes could still execute set-user-ID, set-group-ID
> +or file-capability binaries, which would then run with elevated privileges
> +while being restricted by a Landlock domain they may not expect, making them
> +potential confused deputies.  Setting no_new_privs should only be avoided if
> +such a privilege transition is expected.
> +
> +We now have a ruleset with the first rule allowing read and execute access to
> +``/usr`` while denying all other handled accesses for the filesystem, and two
> +more rules allowing DNS queries.
>  
>  .. code-block:: c
>  
> -    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
> +    /*
> +     * If the ABI > 10, we can tie setting no_new_privs with successful ruleset
> +     * enforcement and skip the manual prctl(PR_SET_NO_NEW_PRIVS, ...) call.
> +     */
> +    if (!(restrict_flags & LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS) &&
> +        prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
>          perror("Failed to restrict privileges");
>          close(ruleset_fd);
>          return 1;
> @@ -792,6 +813,20 @@ when at least one sys_landlock_add_rule() call is made for it with the
>  ``LANDLOCK_ADD_RULE_QUIET`` flag, additional add-rule calls for the same
>  object without this flag do not clear it.
>  
> +no_new_privs flag (ABI < 11)
> +----------------------------
> +
> +Starting with the Landlock ABI version 11, sys_landlock_restrict_self()
> +accepts the ``LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS`` flag, which sets the
> +no_new_privs attribute of the calling thread only once the enforcement of
> +the ruleset succeeded: no_new_privs is set if and only if the call
> +succeeds.  This removes the need for a prior :manpage:`prctl(2)`
> +``PR_SET_NO_NEW_PRIVS`` call, and with it the ``CAP_SYS_ADMIN``
> +requirement.

Reading this looks like CAP_SYS_ADMIN is always a requirement...  What
about:

  +``PR_SET_NO_NEW_PRIVS`` call (or ``CAP_SYS_ADMIN`` use).

> When combined with ``LANDLOCK_RESTRICT_SELF_TSYNC``,
> +no_new_privs is set on all threads of the process.  As explained in the
> +tutorial above, not setting no_new_privs is risky even when it is not
> +required.
> +
>  .. _kernel_support:
>  
>  Kernel support
> -- 
> 2.54.0
> 
>