From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f51.google.com (mail-yx1-f51.google.com [74.125.224.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80ED42777F3 for ; Thu, 23 Apr 2026 16:01:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776960076; cv=none; b=r2ygTZTf+sYv5g/aIyZsW6TNG3TFEa/msNP/0vaSeMoySOaNLXBJB/bQpDkfOuhiR1nOeXG9OBPgdaO8avMvJRU8no4pmUCn9Ot6YLLTcXJZuUVRCveAz31c5Plp2HDamcaQzjKoE6sPp53cHaoGJ23CS+iUSf9OMJDZOz5JmFg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776960076; c=relaxed/simple; bh=Bk99nbE+wjl1xaIdce5kJWj5JEMvga0hgJvweFSnxq4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PdjvHW7/2oTqNtgf11V5K9/aNb0E6P+H5umW96Jv4kI75l85fybNRzv0Zx5ttDQCtlTh3b60uZ5DAfeOCt5t+fdQ/bCuaWZWhCWTffGBhSQ96hZa7iBIQy08fQ8S5yuLoqgbcu2TYo0c0k07Ow91rCaRJjTJc8BnutJSI4j5T4o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Qcif7T9Z; arc=none smtp.client-ip=74.125.224.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Qcif7T9Z" Received: by mail-yx1-f51.google.com with SMTP id 956f58d0204a3-6530287803cso6641207d50.1 for ; Thu, 23 Apr 2026 09:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776960073; x=1777564873; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=f85nHuCkHlesJWLtxMsmerdmkh+GVlSp7tVc32Y/Ev4=; b=Qcif7T9Zf9ecALw0gweZUiOePVlUvRTjvmnRm288PKfSdbGb/b+fqqOwMgQKJYmP/y lZL1VXnxbHoUiF0rAGH55006ALaGltUzpe2wFKsq7ZOOaFaEGIVDhKNeHowM5aMCNSUW 229U0MDtG4Ev6kdvKPJjwdlP6vXJDlAr6IcxZ57ZqLxppVSXWEnkq9fIL/jaMSHuGEZY 9fcAAH5SI13oiTJHcQUDf8kiS1bo2g2+G3Eq6KIf0JXqATcZvlqQw39LYgpBhULou2Fn dZz6ZJ7R7A01lNa+oC4D2ujkbjWycHNG3y9h0Lv0114p9FQ+n1f9gBTVomNbrhBUHupI 7JkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776960073; x=1777564873; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f85nHuCkHlesJWLtxMsmerdmkh+GVlSp7tVc32Y/Ev4=; b=kJoWvfFJ2HSPEH1lfMrjA5QoE4NNrwDm6bpfng6L7a2njEAuzfeDfunoUP0o2J7v7K 8hHAzdt23XLKI8cbfzkfE9gRWYiad6KAvusPWXUOvr6WDoD5qxkJr3VHI2e/JfnM1thl 2rlio7qAAi/E652XLc2+MeCyL3Ad2nJxX6fWCjFpk5utFPVg4pNMR7xBeUxHgCC4ZiHU Rd96Wbn5swDlziAupNYGJUpvQj1zEMkx3ZGw5S10yrQniPGLaNEb6YYeiy6WfxXoDc9l HxDgLHc8nqmf8eNNKn/UTg2AEhDikoV7xnpwnX/c0avdksh66QsVWnawhIAZUaDhFJfC 2wWg== X-Forwarded-Encrypted: i=1; AFNElJ/Qj/EIOG3n6ddH/jxZIFGIdBNHFCzBK0QKy3zoAMxk6j6YNB+qkiyurYAN//9MINhATY4rViNNwf2shSA=@vger.kernel.org X-Gm-Message-State: AOJu0YwF1UrD0O4hxfeWYbrRVcBAKtBNSd2BFObPVooicTbNkvCDGHUm 7cH+VwXi3JWBVQ8j+Jdt4T3d0WAsr8D2fZgcurepvS/BHZokdOjdl3DO X-Gm-Gg: AeBDievUolkIFMszhdsPtIsnJAZI6GycSK7kuhjIAQ9AUREbl30syGLPpVQ8JbI0B7N zvt4plD2zg6wcCg/rAXctawcLLpJ/Rt79+RJxpQWR/0Z42ADNS1sV6nRpE/PWiUEyUFB3aWb7bN mtWncavM9z/qLZBxNo4gGguMP1zeKMNAQpuhz/1OiV4rx911takabvVynTtvqJ8xnmWVsDSiU6w rLY9k4IYxLJY/erQXMHdZeUGmmH3qfFYXkFUo33654GrTY7KuRNCINpkgGt4JX0mA1CUlW8HBei Z5c+LAhm76zusvWTDcv05PBY7OZVQSdt0kDasuc3N/lSFF58IwbL8AnS+Eswkeev/xiNQFNj9YB RPuzVS3E4MppGaaH0F8PH+6Nypxo/4AIND8MkDihpUAAqqoU4iCWiGkJTXmhqhlDnS4q0Cqev48 F8a3IB0husaGGI9HD+bGhewPztgtWFeZWqtcSZtIs5nnMKVQCJA95GfgGFNVsnGOnHjupDaA== X-Received: by 2002:a05:690e:1c1b:b0:652:ddea:1679 with SMTP id 956f58d0204a3-6531080a7c1mr26234083d50.16.1776960070494; Thu, 23 Apr 2026 09:01:10 -0700 (PDT) Received: from suesslenovo ([98.97.172.220]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-65314b26b56sm9625962d50.4.2026.04.23.09.01.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 09:01:10 -0700 (PDT) Date: Thu, 23 Apr 2026 12:01:08 -0400 From: Justin Suess To: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= Cc: Christian Brauner , =?utf-8?Q?G=C3=BCnther?= Noack , Paul Moore , "Serge E . Hallyn" , Lennart Poettering , Mikhail Ivanov , Nicolas Bouchinet , Shervin Oloumi , Tingmao Wang , kernel-team@cloudflare.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [RFC PATCH v1 11/11] landlock: Add documentation for capability and namespace restrictions Message-ID: References: <20260312100444.2609563-1-mic@digikod.net> <20260312100444.2609563-12-mic@digikod.net> <20260423.xai2Pe3theiw@digikod.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260423.xai2Pe3theiw@digikod.net> On Thu, Apr 23, 2026 at 03:51:32PM +0200, Mickaël Salaün wrote: > On Thu, Mar 12, 2026 at 10:48:42AM -0400, Justin Suess wrote: > > On Thu, Mar 12, 2026 at 11:04:44AM +0100, Mickaël Salaün wrote: > > > Document the two new Landlock permission categories in the userspace > > > API guide, admin guide, and kernel security documentation. > > > > > > The userspace API guide adds sections on capability restriction > > > (LANDLOCK_PERM_CAPABILITY_USE with LANDLOCK_RULE_CAPABILITY), namespace > > > restriction (LANDLOCK_PERM_NAMESPACE_ENTER with LANDLOCK_RULE_NAMESPACE > > > covering creation via unshare/clone and entry via setns), and the > > > backward-compatible degradation pattern for ABI < 9. A table documents > > > the per-namespace-type capability requirements for both creation and > > > entry. > > > > > > The admin guide adds the new perm.namespace_enter and > > > perm.capability_use audit blocker names with their object identification > > > fields (namespace_type, namespace_inum, capability). > > > > > > The kernel security documentation adds a "Ruleset restriction models" > > > section defining the three models (handled_access_*, handled_perm, > > > scoped), their coverage and compatibility properties, and the criteria > > > for choosing between them for future features. It also documents > > > composability with user namespaces and adds kernel-doc references for > > > the new capability and namespace headers. > > > > > > Cc: Christian Brauner > > > Cc: Günther Noack > > > Cc: Paul Moore > > > Cc: Serge E. Hallyn > > > Signed-off-by: Mickaël Salaün > > > --- > > > Documentation/admin-guide/LSM/landlock.rst | 19 ++- > > > Documentation/security/landlock.rst | 80 ++++++++++- > > > Documentation/userspace-api/landlock.rst | 156 ++++++++++++++++++++- > > > 3 files changed, 245 insertions(+), 10 deletions(-) > > > > > > diff --git a/Documentation/admin-guide/LSM/landlock.rst b/Documentation/admin-guide/LSM/landlock.rst > > > index 9923874e2156..99c6a599ce9e 100644 > > > --- a/Documentation/admin-guide/LSM/landlock.rst > > > +++ b/Documentation/admin-guide/LSM/landlock.rst > > > @@ -6,7 +6,7 @@ Landlock: system-wide management > > > ================================ > > > > > > :Author: Mickaël Salaün > > > -:Date: January 2026 > > > +:Date: March 2026 > > > > > > Landlock can leverage the audit framework to log events. > > > > > > @@ -59,14 +59,25 @@ AUDIT_LANDLOCK_ACCESS > > > - scope.abstract_unix_socket - Abstract UNIX socket connection denied > > > - scope.signal - Signal sending denied > > > > > > + **perm.*** - Permission restrictions (ABI 9+): > > > + - perm.namespace_enter - Namespace entry was denied (creation via > > > + :manpage:`unshare(2)` / :manpage:`clone(2)` or joining via > > > + :manpage:`setns(2)`); > > > + ``namespace_type`` indicates the type (hex CLONE_NEW* bitmask), > > > + ``namespace_inum`` identifies the target namespace for > > > + :manpage:`setns(2)` operations > > > + - perm.capability_use - Capability use was denied; > > > + ``capability`` indicates the capability number > > > + > > > Multiple blockers can appear in a single event (comma-separated) when > > > multiple access rights are missing. For example, creating a regular file > > > in a directory that lacks both ``make_reg`` and ``refer`` rights would show > > > ``blockers=fs.make_reg,fs.refer``. > > > > > > - The object identification fields (path, dev, ino for filesystem; opid, > > > - ocomm for signals) depend on the type of access being blocked and provide > > > - context about what resource was involved in the denial. > > > + The object identification fields depend on the type of access being blocked: > > > + ``path``, ``dev``, ``ino`` for filesystem; ``opid``, ``ocomm`` for signals; > > > + ``namespace_type`` and ``namespace_inum`` for namespace operations; > > > + ``capability`` for capability use. > > > > > > > > > AUDIT_LANDLOCK_DOMAIN > > > diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst > > > index 3e4d4d04cfae..cd3d640ca5c9 100644 > > > --- a/Documentation/security/landlock.rst > > > +++ b/Documentation/security/landlock.rst > > > @@ -7,7 +7,7 @@ Landlock LSM: kernel documentation > > > ================================== > > > > > > :Author: Mickaël Salaün > > > -:Date: September 2025 > > > +:Date: March 2026 > > > > > > Landlock's goal is to create scoped access-control (i.e. sandboxing). To > > > harden a whole system, this feature should be available to any process, > > > @@ -89,6 +89,72 @@ this is required to keep access controls consistent over the whole system, and > > > this avoids unattended bypasses through file descriptor passing (i.e. confused > > > deputy attack). > > > > > > +Composability with user namespaces > > > +---------------------------------- > > > + > > > +Landlock domain-based scoping and the kernel's user namespace-based capability > > > +scoping enforce isolation over independent hierarchies. Landlock checks domain > > > +ancestry; the kernel's ``ns_capable()`` checks user namespace ancestry. These > > > +hierarchies are orthogonal: Landlock enforcement is deterministic with respect > > > +to its own configuration, regardless of namespace or capability state, and vice > > > +versa. This orthogonality is a design invariant that must hold for all new > > > +scoped features. > > The last sentence on orthogonality may better belong under the restriction > > model section for scoped access rights. I assume that future scopes must > > also be deterministic with respect to landlock's configuration as well, > > not just user namespaces. > > Correct > > > > + > > > +Ruleset restriction models > > > +-------------------------- > > +1 > > > > This section is very helpful for aligning new features with a particular > > model. > > Thanks > > > > > > + > > > +Landlock provides three restriction models, each with different coverage > > > +and compatibility properties. > > Maybe add: > > > > Each restriction model below corresponds to one or more fields of > > ``struct landlock_ruleset_attr``. > > Ok > > > > > > + > > > +Access rights (``handled_access_*``) > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > + > > > +Access rights control **enumerated operations on kernel objects** > > > +identified by a rule key (a file hierarchy or a network port). Each > > > +``handled_access_*`` field declares a set of access rights that the > > > +ruleset restricts. Multiple access rights share a single rule type. > > > +Operations for which no access right exists yet remain uncontrolled; > > > +new rights are added incrementally across ABI versions. > > > + > > > +Permissions (``handled_perm``) > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > + > > > +Permissions control **broad operations enforced at single kernel > > > +chokepoints**, achieving complete deny-by-default coverage. Each > > > +``LANDLOCK_PERM_*`` flag maps to its own rule type. When a ruleset > > > +handles a permission, all instances of that operation are denied unless > > > +explicitly allowed by a rule. New kernel values (new ``CAP_*`` > > > +capabilities, new ``CLONE_NEW*`` namespace types) are automatically > > > +denied without any Landlock update. > > > + > > > +Each permission flag names a single gateway operation whose control > > > +transitively covers an open-ended set of downstream operations: for > > > +example, exercising a capability enables privileged operations across > > > +many subsystems; entering a namespace enables gaining capabilities in a > > > +new context. > > > + > > > +Permission rules identify what to allow using constants defined by other > > > +kernel subsystems (``CAP_*``, ``CLONE_NEW*``). Unknown values are > > > +silently ignored because deny-by-default ensures they are denied anyway. > > > +In contrast, unknown ``LANDLOCK_PERM_*`` flags in ``handled_perm`` are > > > +rejected (``-EINVAL``), since Landlock owns that namespace. > > > + > > > +Scopes (``scoped``) > > > +~~~~~~~~~~~~~~~~~~~~ > > > + > > > +Scopes restrict **cross-domain interactions** categorically, without > > > +rules. Setting a scope flag (e.g. ``LANDLOCK_SCOPE_SIGNAL``) denies the > > > +operation to targets outside the Landlock domain or its children. Like > > > +permissions, scopes provide complete coverage of the controlled > > > +operation. > > > + > > > +When adding new Landlock features, new operations on existing rule types > > > +extend the corresponding ``handled_access_*`` field (e.g. a new > > > +filesystem operation extends ``handled_access_fs``). A new object > > > +category with multiple fine-grained operations would use a new > > > +``handled_access_*`` field. New rule types that control a single > > > +chokepoint operation use ``handled_perm``. > > > + > > > Tests > > > ===== > > > > > > @@ -110,6 +176,18 @@ Filesystem > > > .. kernel-doc:: security/landlock/fs.h > > > :identifiers: > > > > > > +Namespace > > > +--------- > > > + > > > +.. kernel-doc:: security/landlock/ns.h > > > + :identifiers: > > > + > > > +Capability > > > +---------- > > > + > > > +.. kernel-doc:: security/landlock/cap.h > > > + :identifiers: > > > + > > > Process credential > > > ------------------ > > > > > > diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst > > > index 13134bccdd39..238d30a18162 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: January 2026 > > > +:Date: March 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 > > > @@ -33,7 +33,7 @@ A Landlock rule describes an action on an object which the process intends to > > > perform. A set of rules is aggregated in a ruleset, which can then restrict > > > the thread enforcing it, and its future children. > > > > > > -The two existing types of rules are: > > > +The existing types of rules are: > > > > > > Filesystem rules > > > For these rules, the object is a file hierarchy, > > > @@ -44,6 +44,14 @@ Network rules (since ABI v4) > > > For these rules, the object is a TCP port, > > > and the related actions are defined with `network access rights`. > > > > > > +Capability rules (since ABI v9) > > > + For these rules, the object is a set of Linux capabilities, > > > + and the related actions are defined with `permission flags`. > > > + > > > +Namespace rules (since ABI v9) > > > + For these rules, the object is a set of namespace types, > > > + and the related actions are defined with `permission flags`. > > > + > > > Defining and enforcing a security policy > > > ---------------------------------------- > > > > > > @@ -84,6 +92,9 @@ to be explicit about the denied-by-default access rights. > > > .scoped = > > > LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET | > > > LANDLOCK_SCOPE_SIGNAL, > > > + .handled_perm = > > > + LANDLOCK_PERM_CAPABILITY_USE | > > > + LANDLOCK_PERM_NAMESPACE_ENTER, > > > }; > > > > > > Because we may not know which kernel version an application will be executed > > > @@ -127,6 +138,12 @@ version, and only use the available subset of access rights: > > > /* Removes LANDLOCK_SCOPE_* for ABI < 6 */ > > > ruleset_attr.scoped &= ~(LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET | > > > LANDLOCK_SCOPE_SIGNAL); > > > + __attribute__((fallthrough)); > > > + case 6: > > > + case 7: > > > + case 8: > > > + /* Removes permission support for ABI < 9 */ > > > + ruleset_attr.handled_perm = 0; > > > } > > > > > > This enables the creation of an inclusive ruleset that will contain our rules. > > > @@ -191,6 +208,42 @@ number for a specific action: HTTPS connections. > > > err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_NET_PORT, > > > &net_port, 0); > > > > > > +For capability access-control, we can add rules that allow specific > > > +capabilities. For instance, to allow ``CAP_SYS_CHROOT`` (so the sandboxed > > > +process can call :manpage:`chroot(2)` inside a user namespace): > > > + > > > +.. code-block:: c > > > + > > > + struct landlock_capability_attr cap_attr = { > > > + .allowed_perm = LANDLOCK_PERM_CAPABILITY_USE, > > > + .capabilities = (1ULL << CAP_SYS_CHROOT), > > > + }; > > > + > > > + err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_CAPABILITY, > > > + &cap_attr, 0); > > > + > > > +For namespace access-control, we can add rules that allow entering specific > > > +namespace types (creating them via :manpage:`unshare(2)` / :manpage:`clone(2)` > > > +or joining them via :manpage:`setns(2)`). For instance, to allow creating user > > > +namespaces (which grants all capabilities inside the new namespace): > > > + > > > +.. code-block:: c > > > + > > > + struct landlock_namespace_attr ns_attr = { > > > + .allowed_perm = LANDLOCK_PERM_NAMESPACE_ENTER, > > > + .namespace_types = CLONE_NEWUSER, > > > + }; > > > + > > > + err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_NAMESPACE, > > > + &ns_attr, 0); > > > + > > > +Together, these two rules allow an unprivileged process to create a user > > > +namespace and call :manpage:`chroot(2)` inside it, while denying all other > > > +capabilities and namespace types. User namespace creation is the one operation > > > +that does not require ``CAP_SYS_ADMIN``, so no capability rule is needed for it. > > > +See `Capability and namespace restrictions`_ for details on capability > > > +requirements. > > > + > > > When passing a non-zero ``flags`` argument to ``landlock_restrict_self()``, a > > > similar backwards compatibility check is needed for the restrict flags > > > (see sys_landlock_restrict_self() documentation for available flags): > > > @@ -354,10 +407,87 @@ The operations which can be scoped are: > > > A :manpage:`sendto(2)` on a socket which was previously connected will not > > > be restricted. This works for both datagram and stream sockets. > > > > > > -IPC scoping does not support exceptions via :manpage:`landlock_add_rule(2)`. > > > +Scoping does not support exceptions via :manpage:`landlock_add_rule(2)`. > > > If an operation is scoped within a domain, no rules can be added to allow access > > > to resources or processes outside of the scope. > > > > > > +Capability and namespace restrictions > > > +------------------------------------- > > > + > > > +See Documentation/security/landlock.rst for the design rationale behind > > > +the permission model (``handled_perm``) and how it differs from access > > > +rights (``handled_access_*``) and scopes (``scoped``). > > > +When a process creates a user namespace, the kernel grants all capabilities > > > +within that namespace. While these capabilities cannot directly bypass Landlock > > > +restrictions (Landlock enforces access controls independently of capability > > > +checks), they open kernel code paths that are normally unreachable to > > > +unprivileged users and may contain exploitable bugs. > > > + > > > +Landlock provides two complementary permissions to address this. > > > +``LANDLOCK_PERM_CAPABILITY_USE`` restricts which capabilities a process can use, > > > +even when it holds them. ``LANDLOCK_PERM_NAMESPACE_ENTER`` restricts which > > > +namespace types a process can create (via :manpage:`unshare(2)` or > > > +:manpage:`clone(2)`) or join (via :manpage:`setns(2)`). After creating a user > > > +namespace, the granted capabilities are scoped to namespaces owned by that user > > > +namespace or its descendants; to exercise a capability such as > > > +``CAP_NET_ADMIN``, the process must create a namespace of the corresponding type > > > +(e.g., a network namespace). Configuring both permissions together provides > > > +full coverage: ``LANDLOCK_PERM_CAPABILITY_USE`` restricts which capabilities are > > > +available, while ``LANDLOCK_PERM_NAMESPACE_ENTER`` restricts the namespaces in > > > +which they can be used. > > Maybe add a section on the what this does versus PR_SET_NO_NEW_PRIVS. > > Hmm, what do you mean? What would be the link with this part? PR_SET_NO_NEW_PRIVS prevents gaining of privileges through execution, including capabilities (i.e setcap command, not just setuid/gid). So they're adjacent at least. Some users might not want to set NNP because they want to execute a binary with w/ CAP_BPF file capabilities set for instance. But they don't need CAP_SYS_ADMIN or whatever for their usecase. There could be language saying "*hint hint* hey if you can't use NNP, you should really be looking at the capability restrictions". > > > > > The difference might be obvious to people familiar with namespaces and > > capabilities, but not to many users less familiar with the subject. > > > > I could see users using the LANDLOCK_PERM_* flags erroneously > > assuming that LANDLOCK_PERM_CAPABILITY_USE is required to restrict gaining of > > new capabilities through execve(), (ie through setuid) when in fact this is > > already restricted if nnp is set. > > What would be the issue if no rule allow capabilities? The most > handled_* or scoped bits are set, the better. Agreed, the more the better. I just think it would be beneficial to mention the differences up front, especially because NNP won't prevent exercise of existing capabilities, but this will. So the description for this should at least touch on NNP because they are complimentary. I think a lot of devs that just want to add sandboxing aren't deeply familiar with how capabilities work. > > > > > Some clarification on this would be helpful here or where > > PR_SET_NO_NEW_PRIVS is discussed in the Landlock docs. > > Ok, I'll try to add something about NNP. > > > > + > > > +When a Landlock domain handles ``LANDLOCK_PERM_CAPABILITY_USE``, all Linux > > > +:manpage:`capabilities(7)` are denied by default unless a rule explicitly allows > > Nit: > > > > all Linux :manpage:`capabilities(7)` > > > > might be better as > > > > the exercise of all Linux :manpage:`capabilities(7)` > > Indeed > > > [...]