linux – 为什么CLONE_NEWPID需要CAP_SYS_ADMIN？教程

man 2 unshare告诉我们

Use of CLONE\_NEWPID requires the CAP\_SYS\_ADMIN capability

以及建议的读取更多信息man 7 pid\_namespaces并没有真正讨论必须将pid\_namespace限制为root / CAP\_SYS\_ADMIN的可能风险.

如果由非root用户运行,CLONE\_NEWPID的风险是什么？

在没有CLONE\_NEWPID的克隆中,pid\_namespace将保持不变,因此比创建新的空pid\_namespace的情况更广泛且可能更危险.

遗憾的是,如果没有针对非root用户的用户PID命名空间的概念,在Linux中可靠地跟踪后代进程变得困难. pid\_namespaces将是非常方便的功能,因此我无法理解为什么只有CAP\_SYS\_ADMIN被认为适合运行CLONE\_NEWPID.我是否错过了让CLONE\_NEWPID如此危险忙碌的重点？

解决方法:

我认为这是一个预防措施.不允许非特权用户将限制应用于像sudo这样的set-user-id(或具有文件功能集)的程序,以防它们将它们混淆为执行他们不打算允许的操作.

在某些情况下,这是通过set-uid等防止提升来强制执行的.这是使用seccomp过滤系统调用时采用的方法.

但是对于名称空间,意图非常允许使用命名空间用户ID.命名空间在增量过程中合并到主线Linux中,从最简单的用户命名空间开始.我怀疑没有兴趣添加特殊情况,在进入PID命名空间时强制执行no-new-privs,当你还没有完全特权时.

这些名称空间的交互变得非常复杂,所以如果这些案例的需求不是很高,那么不要扩散太多不同的案例是件好事.