简短的回答：它们是两种完全不同的系统。他们只是不同。比较它们有点像比较苹果和橘子。它们是如此根本不同——在很多方面都不同——以至于没有一个句子的比较能真正做到公正。

哦，这对你来说还不够好吗？好的，那么，这是长答案。

背景：强制访问控制。 在我看来，“强制访问控制”（相对于“自由访问控制”）的整个概念是不连贯的。访问控制系统始终是强制性的；访问控制系统的重点是对主题执行一些访问策略。遵守不是自愿的；无论他们喜欢与否，受试者都被迫遵守该政策。所以整个概念是混乱的；任何访问控制系统总是包含强制性元素。

也就是说，许多人使用短语“强制访问控制”来指代基于军事风格分类和信息流控制的一类安全方法。强制访问控制系统通常会引入一些标签层次结构——一个简单的例子可能是“Public”、“Secret”和“Top Secret”，或者“Low”和“Hi”——并用这些标签标记数据。然后，系统会执行一些规则，以确保源自机密数据的任何内容也将被视为机密；当信息在整个系统中传播时，这些规则通常会强制执行标签的分配和更新方式。一个典型的目标是确保绝密机密信息永远不会通过非机密渠道泄露

• （严格来说，这是一个“多级安全”（MLS）系统；虽然 MLS 系统是强制访问控制的一种形式，但人们也可以想象不使用 MLS 的假设强制访问控制系统。但是，由于 MLS 系统作为强制访问控制系统的经典例子，“多级安全”在很多人的脑海中经常与“强制访问控制”混为一谈。冒着混淆的风险，我将继续使用“强制访问控制”这个短语既指一般概念也指多级安全的特定概念，因为这似乎是该术语在文献中的使用方式。）

Bell-Lapadula 是一个理论模型的例子，通常被认为是强制访问控制方法的代表。

SELinux 有时被归类为实现强制访问控制的部署系统，但这可能有点误导。SELinux 至少有两种配置。在严格配置中，SELinux 对系统上运行的每个进程强制执行信息流控制规则。但是，这对于一般用途来说太严格了。因此，这不是 SELinux 在实践中的部署方式。在实践中，采用 SELinux 的 Linux 发行版改为以所谓的“目标”模式部署它。对于大多数意图和目的，目标模式仅限制某些应用程序（有一些适用于所有应用程序的全局规则，但它们非常狭窄）。目标模式由一组关于哪些类型的信息流和访问这些应用程序可以执行的特别规则组成。它只对应用程序的子集施加限制，并且这些限制是部分的。它不尝试提供全面的安全性。它并不试图确保，例如，绝密机密信息永远不会泄露。因此，SELinux——正如它今天所部署的那样——是强制访问控制的淡化版本，与强制访问控制的最初支持者所设想的有所不同。

对象能力系统。 对象能力系统是一种执行授权策略的方法。核心规则是：对特定资源的访问权授予拥有相应能力的人（并且仅在拥有该能力的情况下）；能力可以自由地从一个主体传递给另一个主体；能力是获得访问权的唯一手段。

对象能力系统旨在解决特定问题。设计目标是操作系统应该为表达访问控制策略提供一个非常有限的、简单的基础。因此，操作系统提供了一些非常基本的原语（使用能力的能力，将能力传递给另一个主体的能力），仅此而已。需要实施丰富的访问控制策略的应用程序呢？在对象能力系统中，应用程序被授权使用操作系统提供的基本原语来实现其访问控制需求，而不是为某些应用程序可能需要的每个单独的小东西在操作系统中构建支持。这使操作系统公开的界面保持简单，同时仍保持灵活性并使应用程序能够表达和执行复杂的访问策略。

当心：“POSIX 能力”不是能力。如果您允许我切线，我想提个注意事项。您可能听说过POSIX 功能. 不幸的是，这个名字选得不好。事实上，它们根本不是能力。相反，操作系统识别了一组通常授予传统 Unix 系统中 root 的十几个特殊权限，并允许进程被授予这些权限的子集。然而，它们并没有被进程作为一种能力持有，也没有将它们从一个进程传递到另一个进程的概念。换句话说，尽管名字很不幸，但它们根本不是能力。因此，为防止混淆，我想将它们完全排除在讨论之外（除非您告诉我“POSIX 功能”实际上是您有兴趣了解的内容）。

比较。让我在强制访问控制和功能之间进行一些比较和对比。

• 保密？ 传统上，强制访问控制系统专注于强制执行机密性限制：例如，确保机密数据永远不会泄露给未经机密许可的任何人。相比之下，对象能力系统通常更关注完整性和访问控制。

  原因之一是隐蔽通道：没有门禁系统可以消除隐蔽通道，隐蔽通道允许两个共谋方合谋破坏传统强制访问控制系统的目的。如果 Alice 有权访问秘密数据，并且 Alice 与 Bob 合谋，那么 Alice 可以安排将数据泄露给 Bob，无论任何访问控制系统试图对此说什么。对象能力系统认识到这一点并且不会试图阻止它；他们赞同“不要禁止你无法阻止的事情”的口号。强制访问控制系统试图禁止这种情况，即使它们无法阻止它，并且已发表的强制访问控制工作通常对隐蔽通道回避或完全忽略该问题。

• 可行性？ 不幸的是，传统的强制访问控制策略——尽管其优雅吸引人——却被证明不是很实用。

  主要挑战是“最终所有内容都浮到顶部”的现象，这意味着最终您系统中的几乎所有内容都被标记为最高机密标签：例如，最高机密。为什么？好吧，想象一个包含一些公共数据和一些绝密数据的电子表格。它将被标记为最高机密。一般来说，任何时候你执行任何依赖于秘密和非秘密数据的计算，强制访问控制系统都会将结果标记为秘密。如果 Alice 向 Bob 发送了一条非秘密消息，并且 Bob 被标记为秘密，并且 Bob 向 Alice 返回一个确认，说他收到了她的消息，那么强制访问控制系统通常会将 Alice 标记为秘密（这是为了捕获事实上，确认可能会将秘密信息从 Bob 传递给 Alice）。因此，基本上任何时候秘密数据与非秘密数据混合，都被标记为秘密，并且任何时候有权访问秘密数据的主体与只有非秘密数据的主体交互时，它们都被标记为秘密。这就像一个单向棘轮，导致越来越多的数据/主题被标记为秘密。人们观察到，随着时间的推移，系统的大部分或全部最终都被标记为机密，然后系统对非机密用户变得无用（您可能刚刚说该系统仅适用于绝密数据） . 这使得强制访问控制系统不如人们预期的有用。因此，传统风格的强制访问控制几乎没有部署。任何时候有权访问秘密数据的主体与只有非秘密数据的主体交互时，它们都会被标记为秘密。这就像一个单向棘轮，导致越来越多的数据/主题被标记为秘密。人们观察到，随着时间的推移，系统的大部分或全部最终都被标记为机密，然后系统对非机密用户变得无用（您可能刚刚说该系统仅适用于绝密数据） . 这使得强制访问控制系统不如人们预期的有用。因此，传统风格的强制访问控制几乎没有部署。任何时候有权访问秘密数据的主体与只有非秘密数据的主体交互时，它们都会被标记为秘密。这就像一个单向棘轮，导致越来越多的数据/主题被标记为秘密。人们观察到，随着时间的推移，系统的大部分或全部最终都被标记为机密，然后系统对非机密用户变得无用（您可能刚刚说该系统仅适用于绝密数据） . 这使得强制访问控制系统不如人们预期的有用。因此，传统风格的强制访问控制几乎没有部署。这就像一个单向棘轮，导致越来越多的数据/主题被标记为秘密。人们观察到，随着时间的推移，系统的大部分或全部最终都被标记为机密，然后系统对非机密用户变得无用（您可能刚刚说该系统仅适用于绝密数据） . 这使得强制访问控制系统不如人们预期的有用。因此，传统风格的强制访问控制几乎没有部署。这就像一个单向棘轮，导致越来越多的数据/主题被标记为秘密。人们观察到，随着时间的推移，系统的大部分或全部最终都被标记为机密，然后系统对非机密用户变得无用（您可能刚刚说该系统仅适用于绝密数据） . 这使得强制访问控制系统不如人们预期的有用。因此，传统风格的强制访问控制几乎没有部署。

  现代强制访问控制系统确实试图通过对上面列出的基本 MLS 概念引入各种变体来避免这种有问题的现象。（例如，SELinux 的目标模式通过避免尝试为所有机密数据提供全面的信息流保护来避免“一切都浮到顶部”现象。）但是，这些对传统强制访问控制概念的变体往往会引入它们自己的问题：

• 复杂？ 原则上，强制访问控制和对象能力系统都建立在一个简单而优雅的理论基础之上。然而，在现实世界中，如果强制访问控制系统想要避免“一切都浮到顶部”现象，它们通常会被迫离开这个优雅的基础。

  因此，已部署的强制访问控制系统（如 SELinux）往往非常复杂。即使在其目标模式下，SELinux 的访问控制策略规范也运行到大约十万行访问规则。当出现问题时，这会使系统难以理解。SELinux 因在某些用例中导致难以调试的故障而臭名昭著，在使用 SELinux 的 Linux 发行版上，您经常会看到有人建议用户在遇到难以诊断的系统管理问题时尝试关闭 SELinux .

  到目前为止，已实现的对象能力系统保留了其理论基础的大部分优雅和简单性，因此它们似乎没有受到这种复杂性问题的影响。但是，我们在对象能力系统方面没有太多的实践经验，因此很难确定这种早期经验是否会成立。

• 谁制定政策？ 在强制访问控制系统中，通常设想一些无所不知、仁慈的系统管理员会制定每个人都必须遵守的访问控制策略。然而，在实践中，这会变得非常烦人。我敢肯定，我们都有过这样的经历：某些防火墙或安全系统阻止我们与其他人共享数据，或者某些公司安全策略使我们难以授予与我们合作的人访问权限。发生这种情况时你会怎么做？为什么，当然，以电子邮件附件形式发送。换句话说，让系统管理员为每个人设置安全策略，往往不能反映用户的实际需求，结果是用户绕过安全措施。

  SELinux 类似。在 SELinux 的目标模式中，其想法是无所不知且仁慈的 SELinux 专家将为您可能安装的每个应用程序建立访问策略，指定允许该应用程序访问哪些文件和资源。这些策略必须基于 SELinux 专家对您可能如何使用应用程序以及应用程序可能需要访问的内容的猜测和预测。然而，在现实生活中，SELinux 专家并非无所不知，有时他们无法预料人们会如何使用他们的应用程序——导致 SELinux 策略偶尔会阻止合法程序的行为。

  （原则上，最终用户可以编写自己的 SELinux 策略并修改默认系统策略。实际上，并没有那么多。复杂程度使这种方式超出了大多数最终用户的能力。在实践中，我预计 99.99%的 SELinux 发行版使用默认策略，因为以任何实质性方式修改它都太困难了。）

  相比之下，对象能力系统不依赖专家和消息灵通的系统管理员来为每个人设置策略。相反，每个应用程序都有权根据该应用程序的需要执行其自己的访问策略。因此，访问控制不是由单个中央方预先指定的；相反，它是由应用程序开发人员和用户的联合行动动态决定的。

• 最小特权？ 对象能力系统的好处之一是它们倾向于引导应用程序开发人员采用尊重最小特权原则的设计。因为默认情况下每个应用程序都不会获得访问权限，除了它能够从其他来源获得的任何能力之外，这往往会导致设计中每个应用程序都不会获得比他们需要的更多的权限，并且递归也是如此应用程序的组件和子组件。

  一些强制访问控制系统也试图强制执行最小权限原则。例如，在 SELinux 的目标模式下，SELinux 专家分析每个涵盖的应用程序以确定它可能合法执行的操作以及执行这些操作需要授予哪些安全权限。然后，这些专家编写系统安全策略，指定例如文件列表和网络套接字以及其他资源，例如，sendmail被允许访问。该策略与您的 Linux 发行版一起分发，并且对每个人都是一样的。原则上，这也可以让我们更接近最小特​​权原则，但它的可扩展性很差：它需要少数专家为所涵盖的每个应用程序编写规则，因此它们只能涵盖应用程序的一个子集（因此“针对性”模式）; 它试图以任何形式限制遗留应用程序，这通常意味着无法应用任何有用的限制（尝试考虑如何编写一组 SELinux 规则来限制emacs; 您将允许它访问哪组文件？唯一明智的答案是“一切”，这违背了最小特权原则），而对象能力系统可以通过指导应用程序开发人员以不同的方式编写他们的应用程序来做得更好。

• 部署经验？我们在部署强制访问控制系统方面比在对象能力系统方面拥有更多经验。传统观点认为，传统的强制访问控制系统通常限制性太强，经常阻止人们完成合法任务，尽管这不适用于 SELinux 的目标模式。传统观点认为，对象能力系统不能很好地支持遗留代码，需要我们从头开始，重新设计和重新实现我们的整个系统以及在其上运行的所有应用程序；这可能是对象能力系统的最大缺点。

还有很多要说的，还有很多关于基于能力的安全性、对象能力系统和强制访问控制的文章。这个答案只触及表面。我建议你做一些背景阅读。然后，如果您想了解更多有关的任何方面，请尝试提出更集中的问题。告诉我们一些关于您的特定应用领域、您的要求/目标/顾虑以及您目前所阅读的内容，然后我们可以给您一些更详细的建议。或者，告诉我们更多您想了解的具体内容，我们可以为您提供一些阅读建议。

能力被认为更强大。它们可以防止混淆代理攻击，即应用程序代表他人进行操作，并为减少和委派权限提供清晰的范例。这在应用程序之间进行大量通信的系统中很重要，例如 Android 或微内核系统。事实上，NICTA 宣称，作为 seL4 安全证明的结果，很明显功能是必不可少的，他们还将它们移植到当前的 OKL4。如果没有功能，您需要一个全局命名空间，以便参考监视器（操作系统、微内核）能够查找 MAC 表中的每个应用程序。

米勒等人的“破除能力神话”。很好地概述了一些关键概念。但您可能还想考虑这篇论文从 Usenix Security 中尝试提交时获得的评论： http ://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html

由于我首先误解了您的意思（对不起，Linux 正面！），我将提出另一个答案，因为我不确定是否有任何东西可以为我个人清除。

首先，访问控制领域的情况。

• 所谓的自由访问控制是因为访问控制被委托给某些类型的主体。具体来说，一种主体是用户，另一种是程序。当用户运行程序时，程序原则上“继承”了用户的权限。

• 强制访问控制更细粒度。每个进程（或线程，或更细粒度的主题定义）都被赋予了自己的权限，并且不会从运行它们的用户那里继承（因此是强制性的）任何东西（理论上）。至关重要的是，除非提供的政策中指定，否则他们不会继承。该领域的基石是类型强制的概念——该论文的想法看起来与 SELinux 策略非常相似，正如您毫无疑问地收集到的那样。基本概念是类型可以很宽，也可以很窄，并且您授予进程或应用程序域（主题）对类型（对象集合）的访问权限。

  虽然 MLS、MCS 等与 MAC 密切相关，因为您经常希望通过额外的类别访问或不读取/不写入或两者兼而有之来扩展类型和域，但这样的系统不是没有 TE 的 MAC。这方面的一个例子是强制完整性控制，Windows 中的一个系统实现了基本的不读取、不写入权限，但没有 TE。TE上的另一个链接。

• RBAC与上述两者相似但不同。所以我不分歧；想想 Windows 上的用户组。

在所有这些情况下，您访问受保护资源的过程如下所示：

1. 请求资源。
2. 进入操作系统。操作系统查看 ACL，决定是否允许访问。
3. 操作系统响应。然后过程计算出差异。

从概念上讲，这就像通过电话请求您需要的东西。上述系统都是在这个基础上工作的——你打电话，接线员听你的问题，让你暂停，查阅老板/一些记录，然后回复。

能力不同。能力就像工作通行证。当您挥动带有正确号码的通行证时，它会带您到达您需要去的地方。实际上，要正确扩展它，它更像是有多个通道，每个需要一个。这些需求的精细程度是系统设计的选择，因此现在就回答您的问题 - 这两个系统都允许您在 DAC 所做的工作之外限制流程。

问题是 - 你可能会想“好吧，我的通行证出现了，它仍然需要检查，这仍然意味着一个电话”（进入操作系统进行检查）。是的，它确实; 但这是基于能力的系统的另一面：

• 该令牌必须不能被用户进程修改。这里的类似物是最终用户无法篡改的一次写入存储。就像保证这样的安全性一样，这是一个难题。
• 传递令牌必须有效，就像将通行证交给其他人一样。如果您考虑一下，这是有道理的——在某个时候，某个人、某个地方、一个受信任的人必须创建所有必要的通行证并开始分发它们。

保护程序拥有的这些功能是棘手的部分。事实上，硬件扩展已经被讨论过，但很少被实施。正如 this.josh 所描述的 (+1) 所描述的，L4.sec使用 IPC 来传输能力。鉴于 IPC 是 L4 监督核心为系统其余部分提供的功能（L4 是微内核，因此系统的大部分依赖 IPC），监督核心可以使用 IPC 来检查能力的完整性，因为它们正在运输中并将它们应用于接收过程。

无论如何，回到主题——基于能力的系统要求能力管理是万无一失的。如果你持有令牌，你就会被信任。

它们看起来一样，闻起来一样吗？好吧，表面上都是一种访问控制形式，但底层机制是一个完全不同的概念。在一个系统中，您检查请求；在其他令牌中是密钥，您用生命捍卫这些密钥的完整性。

MAC，在其学术形式中，不是关于访问控制，而是关于信息流。这是一种与能力完全不同的方法。MAC 旨在防止信息从高级别流向低级别或从低级别流向高级别，具体取决于您是否担心完整性或机密性。就是这样分层的。能力不是我理解的；它们只是定义了一个对象可以在平面模型中执行的动作。