我认为基于能力的系统存在很多问题，我们对它们的理解是在野外很少。但是，您很幸运——FreeBSD 刚刚在其 9.0 版本中添加了对辣椒的支持。Capsicum 是一个实施 [轻量级实用功能集][1] 的研究项目。这项工作涉及 Google 安全研究团队的人员，其中包括旨在使用该系统的实验性 chrome 浏览器构建。

您可能最感兴趣的是功能列表：

• 能力 - 具有细粒度权限的细化文件描述符

实际上，将像SELinux 一样运行，但管理方面存在明显差异。与类型标签有类比。

• 进程描述符 - 以能力为中心的进程 ID 替换

类似于 SELinux 域。从用户的角度来看，似乎没有什么不同。

现在，在下一组功能中，您会看到功能尚未普遍使用的原因：

• 匿名共享内存对象 - POSIX 共享内存 API 的扩展，以支持与文件描述符（功能）关联的匿名交换对象
• rtld-elf-cap - 修改后的 ELF 运行时链接器以构建沙盒应用程序
• libcapsicum - 创建和使用功能和沙盒组件的库

尽管 SELinux 需要内核支持和策略，并且可以从那里开始，但配置问题除外，实际实现功能需要修改可用 API 的方法，并随后准备应用程序以访问它们。

现在专门针对您的问题：

它们都可以阻止访问相同的粒度级别吗？

大致可比，是的。例如，SELinux 可以描述一个应用程序域并授予它对某个文件夹的只读权限。基于能力的系统在初始化过程时，根本不会赋予它写入该路径的能力，或者随后拒绝此类请求。它们的实施方式各不相同。

在目标模式下对 SELinux 的攻击可能与对基于能力的操作系统的攻击不同吗？

老实说，这很难说。我不知道有任何大规模部署的基于能力的操作系统会引起足够的兴趣来进行认真的道路测试。但是，我希望最终目标保持不变 - 说服一个进程使用其更高的权限（功能）为您执行代码。它们可能会有所不同，以利用缓冲区溢出如何以相同方式根据目标程序而变化，但最终的基本目标仍然是相同的。

你总是可以试一试。还有关于我谈到的 API 修改的文档。

免责声明：我不以任何方式隶属于 Capsicum 项目、剑桥大学或 FreeBSD 项目。

Capabilities 不同于 Permissions，这就是 SELinux 所说的能力 (doh)。

例如，能力可以移交给其他程序，可能会被削弱。这与访问控制与程序分开管理的基于 ACL 的模型形成对比。

将功能视为对对象的不可伪造的引用，或者可能是对象方法的子集，可以在程序运行时使用。因此，如果我希望某人向我更新报告，我可以向他们传递一种能力（对文件的 rw 接口的引用），他们可以将其提供给代表他们行事的程序。反过来，他们可以通过传递能力将更新过程委托给其他人。我不必打开目录以进行更广泛的访问。

这导致了一种编程风格，其中在设计时考虑安全/信任关系并作为用例的相当自然的扩展：例如，如果我将相机交给某人使用，我也允许他们使用它。