[PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0

[PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0

[Mickaël Salaün]

Commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
records in parent_could_setfcap whether the creator of a user namespace
had CAP_SETFCAP, because a creator writing its own uid_map only has
capabilities in the new namespace.  The snapshot uses cap_raised(), so a
task whose LSM policy denies CAP_SETFCAP can still map uid 0 in a
namespace it creates.

Use security_capable() against the parent namespace instead: the
creator's credentials still belong to it at this point, so commoncap
returns the same result, and only LSM denials are added.

Do not audit this check: creating a user namespace does not use
CAP_SETFCAP, and most namespaces never map uid 0.  The uid_map write
that later fails has no LSM audit record.

Checking CAP_SETFCAP when the map is written would not work: the
writer's credentials then belong to the new namespace, where commoncap
grants the creator all capabilities.

Cc: Christian Brauner <brauner@kernel.org>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Serge Hallyn <serge@hallyn.com>
Cc: stable@vger.kernel.org
Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
Signed-off-by: Mickaël Salaün <mic@digikod.net>
---

This is independent from Josef Bacik's series, which reworks this code
to close other ways around the CAP_SETFCAP rule:
https://patch.msgid.link/20261027-b4-setfcap-userns-v8-0-2674adc63f3c@toxicpanda.com

That series still computes the creator's CAP_SETFCAP with cap_capable()
and cap_raised() in cap_setfcap_level(), so it would need the same
change.
---
 include/linux/user_namespace.h | 5 +++--
 kernel/user_namespace.c        | 8 +++++++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 91232053775d..370961fde45f 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -86,8 +86,9 @@ struct user_namespace {
 	kgid_t			group;
 	struct ns_common	ns;
 	unsigned long		flags;
-	/* parent_could_setfcap: true if the creator if this ns had CAP_SETFCAP
-	 * in its effective capability set at the child ns creation time. */
+	/* parent_could_setfcap: true if the creator of this ns could use
+	 * CAP_SETFCAP in the parent ns at the child ns creation time.
+	 */
 	bool			parent_could_setfcap;
 
 #ifdef CONFIG_KEYS
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index cd748e1cbace..57b7f10be74e 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -128,7 +128,13 @@ int create_user_ns(struct cred *new)
 	if (!ns)
 		goto fail_dec;
 
-	ns->parent_could_setfcap = cap_raised(new->cap_effective, CAP_SETFCAP);
+	/*
+	 * verify_root_map() relies on this once the creator only has
+	 * capabilities in the new namespace.  Let LSMs deny it, but do not
+	 * audit: the creator may never map uid 0.
+	 */
+	ns->parent_could_setfcap =
+		!security_capable(new, parent_ns, CAP_SETFCAP, CAP_OPT_NOAUDIT);
 
 	ret = ns_common_init(ns);
 	if (ret)
-- 
2.56.0

Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0

[sashiko-bot]

> Commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> records in parent_could_setfcap whether the creator of a user namespace
> had CAP_SETFCAP, because a creator writing its own uid_map only has
> capabilities in the new namespace.  The snapshot uses cap_raised(), so a
> task whose LSM policy denies CAP_SETFCAP can still map uid 0 in a
> namespace it creates.
> 
> Use security_capable() against the parent namespace instead: the
> creator's credentials still belong to it at this point, so commoncap
> returns the same result, and only LSM denials are added.
> 
> Do not audit this check: creating a user namespace does not use
> CAP_SETFCAP, and most namespaces never map uid 0.  The uid_map write
> that later fails has no LSM audit record.
> 
> Checking CAP_SETFCAP when the map is written would not work: the
> writer's credentials then belong to the new namespace, where commoncap
> grants the creator all capabilities.
> 
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge Hallyn <serge@hallyn.com>
> Cc: stable@vger.kernel.org
> Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110144205.2404088-1-mic@digikod.net?part=1

Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0

[Paul Moore]

On Tue, Nov 10, 2026 at 9:42 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> records in parent_could_setfcap whether the creator of a user namespace
> had CAP_SETFCAP, because a creator writing its own uid_map only has
> capabilities in the new namespace.  The snapshot uses cap_raised(), so a
> task whose LSM policy denies CAP_SETFCAP can still map uid 0 in a
> namespace it creates.
>
> Use security_capable() against the parent namespace instead: the
> creator's credentials still belong to it at this point, so commoncap
> returns the same result, and only LSM denials are added.
>
> Do not audit this check: creating a user namespace does not use
> CAP_SETFCAP, and most namespaces never map uid 0.  The uid_map write
> that later fails has no LSM audit record.
>
> Checking CAP_SETFCAP when the map is written would not work: the
> writer's credentials then belong to the new namespace, where commoncap
> grants the creator all capabilities.
>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge Hallyn <serge@hallyn.com>
> Cc: stable@vger.kernel.org
> Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---
>
> This is independent from Josef Bacik's series, which reworks this code
> to close other ways around the CAP_SETFCAP rule:
> https://patch.msgid.link/20261027-b4-setfcap-userns-v8-0-2674adc63f3c@toxicpanda.com
>
> That series still computes the creator's CAP_SETFCAP with cap_capable()
> and cap_raised() in cap_setfcap_level(), so it would need the same
> change.
> ---
>  include/linux/user_namespace.h | 5 +++--
>  kernel/user_namespace.c        | 8 +++++++-
>  2 files changed, 10 insertions(+), 3 deletions(-)

Looks reasonable to me.

Acked-by: Paul Moore <paul@paul-moore.com> (LSM)

-- 
paul-moore.com

Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0

[Serge E. Hallyn]

On Tue, Nov 10, 2026 at 03:42:04PM +0100, Mickaël Salaün wrote:
> Commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> records in parent_could_setfcap whether the creator of a user namespace
> had CAP_SETFCAP, because a creator writing its own uid_map only has
> capabilities in the new namespace.  The snapshot uses cap_raised(), so a
> task whose LSM policy denies CAP_SETFCAP can still map uid 0 in a
> namespace it creates.
> 
> Use security_capable() against the parent namespace instead: the
> creator's credentials still belong to it at this point, so commoncap
> returns the same result, and only LSM denials are added.
> 
> Do not audit this check: creating a user namespace does not use
> CAP_SETFCAP, and most namespaces never map uid 0.  The uid_map write
> that later fails has no LSM audit record.
> 
> Checking CAP_SETFCAP when the map is written would not work: the
> writer's credentials then belong to the new namespace, where commoncap
> grants the creator all capabilities.
> 
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge Hallyn <serge@hallyn.com>

Reviewed-by: Serge Hallyn <serge@hallyn.com>

I wonder whether parent_could_setfcap should be renamed
creator_could_setfcap, as now, years later, the name makes me think "the
user namespace's parent ns could do it".

> Cc: stable@vger.kernel.org
> Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---
> 
> This is independent from Josef Bacik's series, which reworks this code
> to close other ways around the CAP_SETFCAP rule:
> https://patch.msgid.link/20261027-b4-setfcap-userns-v8-0-2674adc63f3c@toxicpanda.com
> 
> That series still computes the creator's CAP_SETFCAP with cap_capable()
> and cap_raised() in cap_setfcap_level(), so it would need the same
> change.
> ---
>  include/linux/user_namespace.h | 5 +++--
>  kernel/user_namespace.c        | 8 +++++++-
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
> index 91232053775d..370961fde45f 100644
> --- a/include/linux/user_namespace.h
> +++ b/include/linux/user_namespace.h
> @@ -86,8 +86,9 @@ struct user_namespace {
>  	kgid_t			group;
>  	struct ns_common	ns;
>  	unsigned long		flags;
> -	/* parent_could_setfcap: true if the creator if this ns had CAP_SETFCAP
> -	 * in its effective capability set at the child ns creation time. */
> +	/* parent_could_setfcap: true if the creator of this ns could use
> +	 * CAP_SETFCAP in the parent ns at the child ns creation time.
> +	 */
>  	bool			parent_could_setfcap;
>  
>  #ifdef CONFIG_KEYS
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index cd748e1cbace..57b7f10be74e 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -128,7 +128,13 @@ int create_user_ns(struct cred *new)
>  	if (!ns)
>  		goto fail_dec;
>  
> -	ns->parent_could_setfcap = cap_raised(new->cap_effective, CAP_SETFCAP);
> +	/*
> +	 * verify_root_map() relies on this once the creator only has
> +	 * capabilities in the new namespace.  Let LSMs deny it, but do not
> +	 * audit: the creator may never map uid 0.
> +	 */
> +	ns->parent_could_setfcap =
> +		!security_capable(new, parent_ns, CAP_SETFCAP, CAP_OPT_NOAUDIT);
>  
>  	ret = ns_common_init(ns);
>  	if (ret)
> -- 
> 2.56.0

Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0

[Bradley Morgan]

On 10 November 2026 14:42:04 GMT, "Mickaël Salaün" <mic@digikod.net> wrote:
>Commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
>records in parent_could_setfcap whether the creator of a user namespace
>had CAP_SETFCAP, because a creator writing its own uid_map only has
>capabilities in the new namespace.  The snapshot uses cap_raised(), so a
>task whose LSM policy denies CAP_SETFCAP can still map uid 0 in a
>namespace it creates.
>
>Use security_capable() against the parent namespace instead: the
>creator's credentials still belong to it at this point, so commoncap
>returns the same result, and only LSM denials are added.
>
>Do not audit this check: creating a user namespace does not use
>CAP_SETFCAP, and most namespaces never map uid 0.  The uid_map write
>that later fails has no LSM audit record.
>
>Checking CAP_SETFCAP when the map is written would not work: the
>writer's credentials then belong to the new namespace, where commoncap
>grants the creator all capabilities.
>
>Cc: Christian Brauner <brauner@kernel.org>
>Cc: Josef Bacik <josef@toxicpanda.com>
>Cc: Paul Moore <paul@paul-moore.com>
>Cc: Serge Hallyn <serge@hallyn.com>

Reviewed-by: Bradley Morgan <bradley.morgan@linux.dev>

I'm logging out of mainlining.org (sigh) anything meant to be cc'ing me,
e.g: get maintainers should cc the linux.dev email instead, annoying brr.

>Cc: stable@vger.kernel.org
>Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
>Signed-off-by: Mickaël Salaün <mic@digikod.net>
>---
>
>This is independent from Josef Bacik's series, which reworks this code
>to close other ways around the CAP_SETFCAP rule:
>https://patch.msgid.link/20261027-b4-setfcap-userns-v8-0-2674adc63f3c@toxicpanda.com
>
>That series still computes the creator's CAP_SETFCAP with cap_capable()
>and cap_raised() in cap_setfcap_level(), so it would need the same
>change.
>---
> include/linux/user_namespace.h | 5 +++--
> kernel/user_namespace.c        | 8 +++++++-
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
>diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
>index 91232053775d..370961fde45f 100644
>--- a/include/linux/user_namespace.h
>+++ b/include/linux/user_namespace.h
>@@ -86,8 +86,9 @@ struct user_namespace {
> 	kgid_t			group;
> 	struct ns_common	ns;
> 	unsigned long		flags;
>-	/* parent_could_setfcap: true if the creator if this ns had CAP_SETFCAP
>-	 * in its effective capability set at the child ns creation time. */
>+	/* parent_could_setfcap: true if the creator of this ns could use
>+	 * CAP_SETFCAP in the parent ns at the child ns creation time.
>+	 */
> 	bool			parent_could_setfcap;
> 
> #ifdef CONFIG_KEYS
>diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
>index cd748e1cbace..57b7f10be74e 100644
>--- a/kernel/user_namespace.c
>+++ b/kernel/user_namespace.c
>@@ -128,7 +128,13 @@ int create_user_ns(struct cred *new)
> 	if (!ns)
> 		goto fail_dec;
> 
>-	ns->parent_could_setfcap = cap_raised(new->cap_effective, CAP_SETFCAP);
>+	/*
>+	 * verify_root_map() relies on this once the creator only has
>+	 * capabilities in the new namespace.  Let LSMs deny it, but do not
>+	 * audit: the creator may never map uid 0.
>+	 */
>+	ns->parent_could_setfcap =
>+		!security_capable(new, parent_ns, CAP_SETFCAP, CAP_OPT_NOAUDIT);
> 
> 	ret = ns_common_init(ns);
> 	if (ret)
>

--- Thanks!

Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0

[Christian Brauner]

On Tue, Nov 10, 2026 at 03:42:04PM +0100, Mickaël Salaün wrote:
> Commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> records in parent_could_setfcap whether the creator of a user namespace
> had CAP_SETFCAP, because a creator writing its own uid_map only has
> capabilities in the new namespace.  The snapshot uses cap_raised(), so a
> task whose LSM policy denies CAP_SETFCAP can still map uid 0 in a
> namespace it creates.
> 
> Use security_capable() against the parent namespace instead: the
> creator's credentials still belong to it at this point, so commoncap
> returns the same result, and only LSM denials are added.
> 
> Do not audit this check: creating a user namespace does not use
> CAP_SETFCAP, and most namespaces never map uid 0.  The uid_map write
> that later fails has no LSM audit record.
> 
> Checking CAP_SETFCAP when the map is written would not work: the
> writer's credentials then belong to the new namespace, where commoncap
> grants the creator all capabilities.
> 
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge Hallyn <serge@hallyn.com>
> Cc: stable@vger.kernel.org
> Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---

This seems fine but is another instance where what we really really
really want is for the LSM to be informed where exactly
security_capable() is called from. IOW, it would be nice if the LSM
would know that it is called from the user namespace creation path.

Can be a follow-up but would be nice.

Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0

[Christian Brauner]

On Tue, 10 Nov 2026 15:42:04 +0100, Mickaël Salaün wrote:
> Commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> records in parent_could_setfcap whether the creator of a user namespace
> had CAP_SETFCAP, because a creator writing its own uid_map only has
> capabilities in the new namespace.  The snapshot uses cap_raised(), so a
> task whose LSM policy denies CAP_SETFCAP can still map uid 0 in a
> namespace it creates.
> 
> [...]

Applied to the namespace-7.5.misc branch of the vfs/vfs.git tree.
Patches in the namespace-7.5.misc branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: namespace-7.5.misc

[1/1] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0
      https://git.kernel.org/vfs/vfs/c/2397c70f7645