[PATCH 5/5] capabilities: don't let ptrace borrow CAP_SETFCAP

[sashiko-bot at kernel.org]

> A task that entered a user namespace while it held CAP_SETFCAP outside may
> map uid 0 of the parent and write file capabilities that are honoured
> there.  That is the one privilege it keeps outside of its namespace, and
> the ptrace checks don't know about it: for a target in another user
> namespace cap_ptrace_access_check() is satisfied with CAP_SYS_PTRACE over
> the target's namespace, which the owner rule hands to any task with the
> right euid, and inside the namespace everybody has a full set.
> 
>   task A: uid 0, full caps          task B: uid 0, no CAP_SETFCAP
>   unshare(CLONE_NEWUSER)
>                                     ptrace(PTRACE_ATTACH, A)
>                                       uids match, euid == ns->owner
>                                     make A write "0 0 1" to its uid_map,
>                                     or set file capabilities
>                                       A is entitled -> allowed
> [ ... ]
> tracer's.  PTRACE_MODE_READ is unchanged.
> 
> Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> Assisted-by: LLM
> Signed-off-by: Josef Bacik <josef at toxicpanda.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006-b4-setfcap-userns-v1-0-f47e7ed66072@toxicpanda.com?part=5