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

["Serge E. Hallyn" <serge@hallyn.com>]

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