如果您参考功能手册页,目前没有简单的方法可以做到这一点:
During an execve(2), the kernel calculates the new capabilities of the process
using the following algorithm:
P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset)
P'(effective) = F(effective) ? P'(permitted) : 0
P'(inheritable) = P(inheritable) [i.e., unchanged]
where:
P denotes the value of a thread capability set before the execve(2)
P' denotes the value of a capability set after the execve(2)
F denotes a file capability set
cap_bset is the value of the capability bounding set
如果您要执行的文件没有设置它的 fP 位,或者如果它的 fI 位没有设置,您的进程将没有被允许,因此没有有效的能力。
设置整个文件系统允许和继承位在技术上是可行的,但这没有多大意义,因为它会大大降低系统的安全性,(编辑:正如你提到的,这不适用于新的可执行文件)。
您确实可以使用 pam_cap 为用户提供一些功能,但是您不能让他们执行他们刚刚使用它编译的任何文件。功能是通过设计为程序而不是用户赋予权力的,你可以在Hallyn 的论文中阅读:
一个关键的见解是观察到程序而不是人行使特权。也就是说,在计算机中所做的一切都是通过代理程序——程序——并且只有当这些程序知道如何处理特权时,它们才能被信任使用它。
另请参见定义 POSIX 功能的POSIX 草案1003.1e,第 310 页:
为一个流程链(单个流程中的一系列程序)建立一组在该链的整个生命周期中保持固定和活跃的能力也是不合适的。[...] 这是最小权限原则的应用,它同样适用于用户和进程。
最近(2012 年 12 月)有人要求介绍你想在这个Linux 内核邮件列表中作为一个特性做什么,并且给出了一些非常有趣的答案。有些人认为,在继承规则中删除文件功能exec
会引入一些安全问题,并且功能不是为这样的功能设计的,即使没有解释它会引入哪个安全问题:/
目前唯一的方法是修改 Linux 内核中继承能力的方式(要修改 2 个文件,我在 3.7 内核上成功测试过),但不清楚是否如上所述那样安全。
在旧内核(2.6.33 之前)上,可以选择在没有文件功能的情况下进行编译(CONFIG_SECURITY_FILE_CAPABILITIES
),但我怀疑使用这样的旧内核是否适合您。