why is CAP_SYS_ADMIN needed for CLONE_NEWPID?

Question

man 2 unshare tells us

Use of CLONE_NEWPID requires the CAP_SYS_ADMIN capability

and the suggested reading for further information man 7 pid_namespaces does not really discuss the presumable risk that makes it necessary to restrict pid_namespaces to root/CAP_SYS_ADMIN only.

What would the risk of CLONE_NEWPID be if run by a non-root user?

In a clone without CLONE_NEWPID the pid_namespace would be unchanged and hence much broader and potentially more dangerous than it would be int the case of creating a new empty pid_namespace.

Sadly, without some concept of user PID namespaces for a non-root user, keeping track of descendant processes reliably in Linux becomes difficult. pid_namespaces would be very handy functionality and thus it is incomprehensible to me why only CAP_SYS_ADMIN is thought fit to run CLONE_NEWPID. Did I miss a major point that makes CLONE_NEWPID such risky busyness?

Answer 1

I think it's a precaution. Unprivileged users are not allowed to apply confinements to programs like sudo which are set-user-id (or have file capabilities set), in case it confuses them into performing actions they did not intend to allow.

In some cases this is enforced by preventing elevation by set-uid etc. This is the approach taken when filtering system calls with seccomp.

However for namespaces, the intention was very much to allow namespacing user ids. Namespaces were merged into mainline Linux in an incremental process, starting with the simplest, and culminating in user namespaces. I suspect there was little interest in adding the special case, to enforce no-new-privs when entering a PID namespace, when you do not already have full privilege.

The interaction of these namespaces becomes quite intricate, so it's nice not to proliferate too many different cases, if those cases are not in very high demand.