* Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0
2026-11-10 14:42 [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0 Mickaël Salaün
@ 2026-11-10 14:51 ` Paul Moore
2026-11-10 15:08 ` Serge E. Hallyn
2026-11-10 15:51 ` Bradley Morgan
2 siblings, 0 replies; 4+ messages in thread
From: Paul Moore @ 2026-11-10 14:51 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Josef Bacik, Serge Hallyn, Christian Brauner, James Morris,
David Howells, Jarkko Sakkinen, Andrew G. Morgan, Serge Hallyn,
linux-security-module, linux-kernel, keyrings, linux-fsdevel,
Bradley Morgan, stable
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0
2026-11-10 14:42 [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0 Mickaël Salaün
2026-11-10 14:51 ` Paul Moore
@ 2026-11-10 15:08 ` Serge E. Hallyn
2026-11-10 15:51 ` Bradley Morgan
2 siblings, 0 replies; 4+ messages in thread
From: Serge E. Hallyn @ 2026-11-10 15:08 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Josef Bacik, Paul Moore, Christian Brauner, James Morris,
David Howells, Jarkko Sakkinen, Andrew G. Morgan, Serge Hallyn,
linux-security-module, linux-kernel, keyrings, linux-fsdevel,
Bradley Morgan, stable
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0
2026-11-10 14:42 [PATCH] userns: Let LSMs deny the CAP_SETFCAP snapshot for mapping uid 0 Mickaël Salaün
2026-11-10 14:51 ` Paul Moore
2026-11-10 15:08 ` Serge E. Hallyn
@ 2026-11-10 15:51 ` Bradley Morgan
2 siblings, 0 replies; 4+ messages in thread
From: Bradley Morgan @ 2026-11-10 15:51 UTC (permalink / raw)
To: mic
Cc: brads, brauner, dhowells, jarkko, jmorris, josef, keyrings,
linux-fsdevel, linux-kernel, linux-security-module, morgan, paul,
serge, sergeh, stable
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!
^ permalink raw reply [flat|nested] 4+ messages in thread