Re: [PATCH v10 2/3] capabilities: don't let ptrace borrow CAP_SETFCAP

[sashiko-bot@kernel.org]

> A uid 0 task that gave up CAP_SETFCAP and CAP_SYS_PTRACE can still
> attach to a task in a user namespace that another root task created,
> and have it write file capabilities for its root user.  For a target in
> a child namespace cap_ptrace_access_check() asks for CAP_SYS_PTRACE over
> that namespace, and cap_capable() grants every capability there to a
> task whose euid owns it, whatever it gave up:
> 
>   task A: uid 0, full caps          task B: uid 0, no CAP_SETFCAP,
>   unshare(CLONE_NEWUSER)              no CAP_SYS_PTRACE
>                                     ptrace(PTRACE_ATTACH, A)
>                                       euid == ns->owner -> allowed
>                                     make A write "0 0 1" to its uid_map,
>                                     or set file capabilities
> 
> The same goes for /proc/<pid>/mem, process_vm_writev() and
> [ ... ]
> 
> Suggested-by: Serge Hallyn <serge@hallyn.com>
> Link: https://lore.kernel.org/all/fd159e68-c613-4c7d-bfba-8af0a3f3a96e@hallyn.com/
> Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112-b4-setfcap-userns-v10-0-84f6f7faa903@toxicpanda.com?part=2