[PATCH v2 2/5] userns: don't let setns() lend CAP_SETFCAP

Bradley Morgan brads at mainlining.org
Wed Oct 14 20:54:56 UTC 2026


On 14 October 2026 21:47:47 BST, Josef Bacik <josef at toxicpanda.com> wrote:
>Mapping uid 0 of the parent into a user namespace requires CAP_SETFCAP,
>because a task in such a namespace can write file capabilities that are
>honoured in the parent.  A task that is already in the namespace has a
>full capability set there and can't be asked any more, so
>verify_root_map() goes by what the creator had, now ns->setfcap_level.
>
>But setns() lets other tasks in, and they get the full set as well:
>
>  task A: uid 0, full caps          task B: uid 0, no CAP_SETFCAP
>  unshare(CLONE_NEWUSER)
>                                    setns(A's user ns)
>                                      allowed, euid == ns->owner
>                                    write "0 0 1" to /proc/self/uid_map
>                                      ns->setfcap_level is A's -> allowed
>
>or, if A's namespace maps uid 0 already, B sets security.capability on a
>file.  Either way B ends up with file capabilities that are honoured in
>the initial namespace, which it could not have written there, nor in a
>namespace it created itself.
>
>Refuse setns() into a user namespace unless the joiner's CAP_SETFCAP
>reaches at least as far up as the namespace's setfcap_level.  Then every
>task in a namespace is entitled to what its setfcap_level says, and the
>checks on the way to file capabilities can go by the namespace.  This
>has to apply to every user namespace, also to those that don't map the
>parent's uid 0: through an idmapped mount, a root user that only exists
>in the namespace can be stored as the parent's.
>
>The change in behaviour is that a task without CAP_SETFCAP gets -EPERM
>when it tries to setns() into a user namespace created by a task that
>had it, such as a root-created container.  Tasks with CAP_SETFCAP, and
>unprivileged users joining their own namespaces, are not affected.

Gnarly.

>
>Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
>Assisted-by: LLM

Ok.

>Signed-off-by: Josef Bacik <josef at toxicpanda.com>
>---
> kernel/user_namespace.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
>index a5a94367600d..330085a7d7d4 100644
>--- a/kernel/user_namespace.c
>+++ b/kernel/user_namespace.c
>@@ -1390,6 +1390,13 @@ static int userns_install(struct nsset *nsset, struct ns_common *ns)
> 	if (!ns_capable(user_ns, CAP_SYS_ADMIN))
> 		return -EPERM;
> 
>+	/* Everybody in the namespace gets CAP_SETFCAP that reaches as far up
>+	 * as its setfcap_level, so only let in tasks whose own reaches as far.
>+	 */

Wow!

>+	if (cap_setfcap_level(current_cred(), user_ns->parent) >
>+	    user_ns->setfcap_level)
>+		return -EPERM;
>+

Clean! Please add 

Reviewed-by: Bradley Morgan <brads at mainlining.org>

> 	cred = nsset_cred(nsset);
> 	if (!cred)
> 		return -EINVAL;
>
>


--- Thanks!
"I'm not a very positive person" - Linus torvalds



More information about the Linux-security-module-archive mailing list