关于自主访问控制(Discretionary Access Control, abbr. DAC)的分析

参考资料

• 自主访问控制 - 维基百科(英文)

为什么计算机是易受攻击的(Vulnerable)?

• 计算机程序往往充满了Bug
• 人类程序员会犯错
• 访问控制做的不够好
  • 在Unix和Windows系统中使用的自主访问控制(Discretionary Access Control, abbr. DAC)假定所有程序不存在Bug

访问控制检查

• 给出一个访问请求，返回一个基于策略(policy)的访问控制决定
  • 返回允许或者拒绝

自主访问控制

• 自主访问控制这一概念没有精确的定义。 其基本概念是，DAC允许主体自行传播访问权限。

  • 通常有一个对象的所有者的概念
  • 在UNIX、Windows等系统中使用。

• 根据可信的计算机系统评估标准(Trusted Computer System Evaluation Criteria, abbr. TCSEC)的规定:

  • 它是根据主体（如用户、进程或 I/O 设备等）的身份和主体所属的组，来限制对对象的访问的方法。对访问权限的控制是自主的，即拥有某项访问权限的主体可以将该权限（直接或间接地）传递给任何其他主体。

TIP

所谓的自主（Discretionary，拥有自由裁量权的），是因为拥有访问权限的主体，可以直接（或间接）地将访问权限赋予其他主体（除非受到强制访问控制的限制）。

所有者有权自行进一步分享。

Q: 什么是自主访问控制？

A(AI生成):

自主访问控制（Discretionary Access Control，DAC）是计算机系统中使用的一种安全模型，根据资源所有者的自主权来调控对资源的访问。在DAC中，资源所有者有权决定谁能够访问其资源以及所拥有的访问级别。

在自主访问控制系统中，每个资源（如文件、文件夹或设备）都与一个访问控制列表（Access Control List，ACL）相关联，该列表规定了不同用户或组的权限或访问权。访问控制列表通常包含用户或组及其相应权限的列表，如读取、写入、执行或删除等。

自主访问控制的关键特点包括：

资源所有者自主权：资源所有者有权决定谁能够访问资源以及所拥有的访问级别。所有者可以修改访问控制列表，根据需要授予或撤销访问权限。

个别用户权限：为每个用户或组分配特定的资源访问权限。这些权限确定用户对资源可以执行的操作，如读取、修改或删除等。

访问控制列表：使用访问控制列表来定义和管理资源的权限。访问控制列表包含用户或组的条目以及其关联的权限。

简单灵活：DAC是一种简单的访问控制模型，易于理解和实现。它通过允许资源所有者对访问权限进行细粒度控制来提供灵活性。

自主访问控制的一个限制是它仅依赖于资源所有者的自主权，有时可能导致不一致或不适当的访问决策。其他访问控制模型，如强制访问控制（Mandatory Access Control，MAC）和基于角色的访问控制（Role-Based Access Control，RBAC），旨在通过提供更严格和更标准化的访问控制机制来解决这些限制。

强制访问控制（MAC）： 强制访问控制是一种更严格的访问控制模型，与自主访问控制相比，它将访问控制的决策从资源所有者转移到了系统管理员或安全策略制定者。在MAC中，每个资源和主体（用户或进程）都被赋予一个安全级别或标签，这些级别基于安全策略和需求进行定义。资源的访问权限由系统根据其安全级别和主体的安全级别进行强制执行，而不是由资源所有者自主决定。这种模型可以实现更严格的访问控制，以确保资源的保密性和完整性。

基于角色的访问控制（RBAC）： 基于角色的访问控制是一种将权限分配与用户角色相关联的访问控制模型。在RBAC中，用户被分配到不同的角色，而角色则与特定的权限集相关联。用户通过担任特定角色来获得与该角色关联的权限。这种模型使得访问控制管理更加集中化和易于管理。相比自主访问控制，RBAC提供了更标准化和可扩展的访问控制机制，并且可以更容易地适应组织的变化和复杂性。

基于角色的访问控制相比自主访问控制提供了更加标准化和可扩展的访问控制机制。以下是原因：

标准化：RBAC通过将权限与预定义角色相关联，引入了一种结构化的访问控制方法。角色代表组织内的工作职能或责任。这种标准化使得访问控制策略的管理和维护更加容易。不再需要为每个用户分配权限，而是将权限分配给角色，并根据用户的工作要求将其分配到适当的角色中。这简化了访问控制的管理，并确保组织内的一致性。

可扩展性：RBAC非常适合具有复杂访问控制需求的大型组织或系统。随着组织的发展或变化，可以定义或修改新角色以适应不断变化的访问需求。添加或删除用户变得更加简化，因为他们的访问权限取决于其角色成员资格。这种可扩展性使得RBAC能够适应组织的动态变化和规模，而不会影响安全性或需要大量的行政开销。

职责分离：RBAC允许职责的分离，这对于减轻未经授权的活动或欺诈风险至关重要。通过为不同的个体分配具有特定权限的不同角色，RBAC确保没有单个用户拥有过多的特权或对关键操作拥有完全控制。这种分离有助于执行安全策略，并最大程度地减少滥用或未经授权访问的可能性。

关于DAC缺陷的分析

• DAC 导致“困惑的副手问题”(Confused Deputy problem)
  • 解决方案：使用基于权能的(capability-based)访问控制系统
• DAC 在面对木马时无法保持机密性
  • 解决方案：使用强制访问控制（Bell-LaPadula模型，在这个模型中，用户不能下写、不能上读）
• DAC 实施未能跟踪一个主体（进程）代表哪些授权主体(principal)执行操作
  • 解决方案：改进 DAC 的实现以更好地跟踪授权主体

困惑的副手问题：DAC 可能导致困惑的副手问题，即拥有特定访问权限的主体可能会被欺骗或操纵，代表另一个实体执行其不应该访问的操作。这会带来安全风险，因为主体超出了其预期权限。解决这个问题的方法是使用基于权能的系统，在此系统中，访问是基于特定权能或令牌授予的，而不仅仅依赖于主体的权限。

木马病毒下的机密性缺失：DAC 在面对木马病毒或恶意代码时无法有效解决机密性问题。如果拥有访问权限的主体受到木马病毒的侵害，恶意代码可以利用主体的权限，未经授权地访问敏感数据。为了降低这种风险，可以实施强制访问控制（MAC）系统，如贝尔-拉帕杜拉模型（BLP）。MAC 根据安全标签强制执行严格的访问控制，防止信息从较高安全级别流向较低安全级别，从而保护机密性。

执行授权主体的跟踪不足：DAC 实施通常无法跟踪一个主体（进程）代表哪些授权主体执行操作。这种缺乏问责和审计可能导致难以识别和追踪行动的责任方。为了解决这个问题，关键是改进 DAC 实施，更好地跟踪和记录与每个主体行动相关的授权主体。这增强了问责权能，并有助于在发生安全事件或违反政策时进行调查。

“困惑的副手问题”(The Confused Deputy problem)

TIP

编译器程序是SYSX/FORT。

SYSX目录下的其他文件包括STAT和BILL。

编译器程序需要向SYSX目录中的文件写入数据，因此它被授予在SYSX中写入文件的权限。 运行SYSX/FORT的用户可以提供一个文件名来接收输出信息。

恶意用户可能会将SYSX/BILL作为输出文件名，导致BILL文件中原先的内容被删除。

关于“困惑的副手问题”的分析

• 编译器从两个源头获取权限
  • 调用者（即程序员）
  • 系统管理员（安装编译器并控制计费(向SYSX/BILL文件写入账单)和其他信息）
• 编译器是两个主体的副手
• 在执行写操作时，无法确定副手是为哪个主体提供服务
• 解决方案：使用使用基于权能的(capability-based)访问控制系统

对于“编译器是两个主体的副手”这一表述，它指的是编译器具有的双重权限或控制。编译器从两个不同的来源获得权限：调用者（程序员）和系统管理员。

作为“副手”，编译器代表两个主体行事，即根据程序员和系统管理员的委派执行任务和操作。程序员依赖编译器将其代码解释和转换为可执行指令，而系统管理员则安装了编译器并管理与系统相关的方面，如计费和其他信息，对编译器的安装和使用拥有控制权。

然而，这也意味着编译器在决策或优先级方面不偏向任何一方。它以中立和公正的方式行事，不对程序员或系统管理员偏袒，执行其功能而不带有任何偏见。

“在执行写操作时，无法确定副手是为哪个主体提供服务”表明，在进行写操作时，不可能确定或归因于编译器的行动是程序员还是系统管理员的独立影响。这种不明确性可能导致在写操作时出现所有权或责任方面的混淆或模糊。

提出的解决方案是使用基于权能的访问控制系统，通过使用基于权能的访问控制，可以更精确地定义和归属于特定来源的编译器的权限和授权，确保对其行为的明确性和控制。

在这个有关编译器的例子中，使用基于权能的访问控制意味着实施一个访问控制系统，它向编译器授予特定的权限或权能。这些权能定义了编译器被允许执行的操作，并与特定的来源或实体（如程序员或系统管理员）相关联。

不再仅依赖于程序员和系统管理员授予的一般权限，编译器将具有明确的权能来确定其访问和权限。这些权能可以细粒度地指定编译器被允许执行的操作或行为。

例如，程序员授予编译器的权能可能包括读取和编译源代码文件、优化代码和生成可执行文件的权能。而系统管理员授予的权能可能包括访问系统资源、使用特定库或API以及执行必要的计费操作的权能。

通过使用基于权能的访问控制，授予编译器的权限和许可变得更加精确地定义和归属于特定的来源。这确保了对编译器行为的明确性和控制，因为每个权能与特定的功能或任务相关联。

在实际操作中，基于权能的访问控制可以涉及实施一个系统，为编译器分配特定的令牌或权限，使其能够访问特定资源或执行特定操作。这些令牌可以由底层系统验证和执行，确保编译器仅具有经过授权的权能，并且不能超出其定义的边界。这种方法提供了一种更精确和受控的方式来确定编译器的访问和权限，增强安全性并减少模糊性。

TIP

Q: “困惑的副手问题”是如何在UNIX访问控制系统中被解决的? A(由AI生成)：

在UNIX访问控制系统中，通过最小权限原则（Principle of Least Privilege）和权限分离（Separation of Privileges）来缓解这个问题。

在UNIX中，该问题通过同时实施自主访问控制（DAC）和强制访问控制（MAC）机制来解决。

• 自主访问控制（DAC）：UNIX使用DAC作为主要的访问控制机制。DAC允许资源所有者确定其资源的访问权限。通过使用chmod命令设置适当的文件权限（例如，对所有者、组和其他用户的读取、写入、执行权限），资源所有者可以限制对其文件的访问。
  • 最小权限原则：最小权限原则是一个基本的安全原则，将访问权限限制在实现特定任务所需的权限范围内。在UNIX中，程序通常以调用它们的用户的权限而不是提升的权限来执行。这有助于防止程序执行超出其预期功能范围的操作。
  • 权限分离：UNIX采用模块化设计，不同的组件具有单独的权限，并在隔离的环境中运行。例如，需要提升权限的系统进程（如管理网络连接或配置系统设置）以较高的权限（例如，root或管理员访问权限）执行。常规用户程序以启动它们的用户的权限执行，提供一定程度的隔离并限制其潜在影响。

通过结合DAC、最小权限原则和权限分离，UNIX访问控制系统减轻了困惑的副手问题带来的影响。资源所有者可以定义访问权限，程序以受限权限执行，确保它们只能执行资源所有者允许的操作，并防止执行未经授权的操作或访问敏感系统资源。

访问控制矩阵模型 (Access matrix model)

TIP

这张图复习了有关访问控制矩阵模型的概念.

访问控制矩阵模型的实现

• 访问控制列表(Access Control Lists)
  • 编码矩阵中的列
• 权能(Capabilities)
  • 编码矩阵中的行
• 访问控制三元组(Access control triples)
  • 编码矩阵中的每一个元胞

访问控制列表(Access Control Lists, abbr. ACLs)

• 访问控制矩阵中的每一个列被存储在与这一列相关的访问控制客体中

权能列表(Capabilities)

• 访问控制矩阵中的每一个行被存储在与这一行相关的访问控制主体中

访问控制三元组(Access control triples)

• 在关系型数据库管理系统(relational DBMS)中常用的访问控制三元组用于指定和实施访问控制策略。

在关系型数据库管理系统(relational DBMS)中常用的访问控制三元组用于指定和实施访问控制策略，访问控制三元组由三个元素组成：主体（Subject）、对象（Object）和权限（Permission）。这些元素定义了主体（用户或进程）、对象（数据或资源）以及主体对对象所允许的权限或操作之间的关系。

主体代表着正在寻求访问或执行操作的实体。它可以是个别用户、用户组或进程。对象表示被访问或受保护的资源或数据，例如表、文件或数据库中的特定记录。权限定义了主体对对象所授予的具体操作或权限，如读取、写入、更新或删除等。

通过定义访问控制三元组，管理员可以建立精细的访问控制策略，管理数据库中主体和对象之间的交互。这些三元组通常存储在访问控制矩阵或类似的数据结构中，以实现对访问控制规则的高效查找和执行。

当主体尝试在对象上执行操作时，访问控制机制会检查访问控制三元组，以确定主体是否具有所请求操作所需的权限。如果主体的访问权限与访问控制三元组中指定的权限匹配，操作将被允许进行。否则，访问将被拒绝，主体将被阻止执行所请求的操作。

访问控制三元组在关系型数据库管理系统中提供了一种灵活和可定制的访问控制方法。它们使管理员能够以细粒度管理访问权限，确保只有授权实体可以对受保护的资源执行特定操作。

权能（Capabilities）的不同概念

• 权能作为访问矩阵的行被表示
• 权能在Linux中的使用：将root权限分割成多个独立的、可以单独分配的部分
• 权能作为实现整个访问控制系统的一种方式
  • 主体拥有权能，可以传递
  • 当访问资源时，主体选择权能进行访问
    • 一个例子是打开的文件描述符
  • 我们将更深入地研究这最后一个概念

更多关于基于权能的访问控制

• 主体拥有权能
  • 给予它们对资源的访问权限
    • 类似于钥匙
  • 权能是可转让和无法伪造的授权令牌
    • 可以从一个进程传递给另一个进程
      • 类似于已打开的文件描述符
• 为什么权能可以解决困惑的副手问题？
  • 当访问资源时，必须选择一个权能，这也选择了一个主体的权威

这个说法中的“类似于打开的文件描述符”指的是权能和打开的文件描述符在可转移性和使用方式上的相似性。在文本的语境中，权能被描述为可转移且不可伪造的权限令牌，可以在进程之间传递。这个概念与打开的文件描述符进行了比较，后者在某些操作系统中也可以在进程之间传递。

就像打开的文件描述符允许进程访问和操作特定的文件或资源一样，权能提供了一种进程或主体以受控方式访问和交互资源的手段。这种比较强调了权能和打开的文件描述符作为授予和管理资源访问的机制的共同特征，尽管在访问控制系统的背景下，权能是一个更广泛的概念。

TIP

例子：一个秘书为两位姓李的教职人员工作，但将一个人的账单记入另一个人的账户。

在访问控制列表（ACL）中，两位教职人员都授权秘书可以向他们的账户记账。这可能导致混淆。

在基于权能的系统中，秘书被授予记账的权利，这些权利以令牌的形式存在。当秘书处理其中一位教职人员的账单时，必须提供相应的权能令牌，以避免混淆。

使用权能的概念如何解决“困惑的副手问题”

• 调用者必须为$OUTPUT传入一个权能，它被存储在槽3中。
• 写入输出时使用槽3中的权能。
• 调用者不能传递一个它没有的权能。

TIP

编译器程序被赋予访问SYSX/STAT和SYSX/BILL的权能，这些权能被存储在权能槽1和2中 当调用者运行编译器程序时，他提供了一个权能用于写入输出文件，该权能存储在权能槽3中。如果调用者没有SYSX/BILL的权能，就不能给它一个对应的权能。 当写计费信息（写入SYSX/BILL）时，程序使用槽2的权能。 当写输出时，程序使用槽3的权能。

权能与访问控制列表的对比

• 考虑两种银行账户的安全机制。
• 其中一种是基于身份的。每个账户有多个授权所有者。你去银行出示身份证明，然后可以访问您被授权的所有账户。
  • 一旦出示身份证明，你可以访问所有账户。
  • 你必须告诉银行从哪个账户取款。
• 另一种是基于令牌的。当开设一个账户时，您会得到一个属于该账户的通行证和一个PIN码，只要持有通行证和PIN码的人可以访问账户。

权能与访问控制列表的对比: 环境权限(Ambient Authority)

• 环境权限意味着用户的权限会自动被执行，无需进行选择。
  • 这会导致困惑的副手问题。
• 权能系统中没有环境权限。

TIP

例如，你带了很多钥匙。当你走到一扇门前时，如果你有正确的钥匙，门会自动打开。你不需要选择一把钥匙。当你为多个主人工作时，这会引发问题。

权能与访问控制列表的对比: 命名(Naming)

• 基于ACL的访问控制系统需要为对象提供命名空间。
• 在基于权能的访问控制系统中，一个权能可以既用于指定资源，也用于提供权限。
• 基于ACL的访问控制系统还需要为主体或授权主体提供命名空间。
  • 因为它们(这些系统)需要引用主体或授权主体。
• 影响
  • 主体的集合不能太多或过于动态。
  • 大多数基于ACL的访问控制系统中，通常将权限或许可授予用户账户或授权主体。并不支持细粒度的主体权限管理。

在基于ACL的访问控制系统中，通常将权限或许可授予用户账户或授权主体。让我们来详细解释一下：

用户账户：在ACL系统中，用户被分配个别的用户账户。每个用户账户代表系统内的唯一身份，并与特定的权限和访问权限相关联。用户账户通常针对与系统进行交互的个别用户或实体而创建。

授权主体：ACL系统中的授权主体指被授予访问权限或权限的实体或主体。它们可以包括个别用户、组、角色或其他在系统中被认可和管理的实体。授权主体用于表示可以被分配或限制访问权限的实体。

在配置ACL系统中的访问控制时，权限或访问权限被授予这些用户账户或授权主体。这意味着特定的用户或实体会被明确分配某些权限，例如读取、写入、执行或管理权限，以执行系统内的特定资源或操作。

例如，在文件系统的ACL中，特定的用户或组可能会被授予某些文件的读取和写入权限，而其他用户只能具有只读访问权限。访问控制基于与系统相关联的用户账户或授权主体。

然而，需要注意的是，基于ACL的访问控制系统在细粒度授权主体权限管理方面可能存在一些限制。在某些ACL实现中，管理大量授权主体或动态更改授权主体集合可能变得复杂或具有挑战性。这就是基于权能的系统提供了另一种方法的地方，因为权能可以在管理访问权限和权限方面提供更大的灵活性和粒度。

关于为什么大多数的现实世界操作系统采用ACL而不是Capabilities的推测

• 权能更适合进程级别的共享，而不是用户级别的共享 = 用户级别的共享才是真正所需的
• 在基于权能的系统中，进程之间更紧密地耦合，因为需要传递权能
  • 编程可能更加困难

TIP

另一方面，当一个用户与另一个用户共享文件时，访问该文件的主体尚不存在。因此，需要存在一种命名方案。

DAC 的固有弱点

• 无限制的 DAC 允许信息从一个可以被读取的对象流向任何一个可以被主体写入的对象
  • 假设 A 被允许读取某些信息而 B 不被允许，A 可以读取并告诉 B
• 即使我们相信用户不会故意这样做，但是木马程序仍然可以将信息从一个对象复制到另一个对象中。

“未受限的自主访问控制（DAC）允许信息从一个可读对象流向任何一个被主体写入的对象”指的是自主访问控制系统中的一个漏洞或弱点。

在自主访问控制系统中，对象（如文件或资源）的访问权限由对象的所有者或创建者决定。所有者可以自行决定谁可以读取、写入或修改对象。然而，当自主访问控制在没有适当的限制或约束的情况下实施时，就可能导致意外的信息流动。

以下是一个例子来说明这个弱点：

对象A：包含着只有授权人员可以访问的敏感信息。 主体B：是一个具有读取对象A权限的用户或进程。

在未受限制的自主访问控制系统中，如果主体B被授予了读取对象A的权限，它有可能将对象A中的信息与任何其他它被授予写入权限的对象共享。这意味着主体B可以将对象A中的敏感信息复制或转移至另一个对象，而无论该对象是否打算存储相同级别的敏感信息或访问限制。

即使用户被认为不会故意滥用权限，这个漏洞仍然存在信息泄漏或意外信息流动的风险。它为未经授权的对象或实体通过合法途径获得敏感信息开启了可能性。

此外，自主访问控制系统中的这个弱点可以被恶意行为者或木马程序所利用。木马程序可以利用未受限制的自主访问控制权限在不被察觉的情况下将信息从一个对象复制或转移至另一个对象。这允许未经授权的提取或复制敏感数据，从而危及系统的安全性和完整性。

为了解决这个弱点，可以采取额外的访问控制机制，如强制访问控制（MAC）或更精细的控制，以限制信息流动并防止未经授权的数据泄漏。

一个木马程序的例子

• 初始状态下，授权主体B不能够阅读文件F。

• 授权主体A能够执行含有木马的程序，这个程序将文件F复制到文件G。

• 在此时，授权主体B可以阅读被复制到G的文件F的内容。

有漏洞的软件可能成为木马程序

• 当有漏洞的软件被利用时，它会执行攻击者的代码/意图，同时使用启动它的用户的权限。
• 这意味着仅使用自主访问控制（DAC）的计算机无法被信任用于处理不同级别的机密信息。
  • 强制访问控制（MAC）是为解决这个问题而开发的
  • 我们将在下一个章节中介绍MAC。

Q: 你能为我大致解释一下“强制性访问控制是如何解决这个问题”吗？

A(AI生成)：

强制访问控制（Mandatory Access Control，MAC）是为了解决自主访问控制（Discretionary Access Control，DAC）系统的限制和漏洞，特别是针对DAC实施不当导致的意外信息流问题。

在DAC系统中，对象的所有者或创建者有权自行设置决定谁能访问和修改该对象的权限。然而，当DAC在没有适当限制或限定的情况下实施时，可能会导致意外的信息流。这意味着信息可能从一个可以读取的对象流向另一个可以被主体写入的对象，即使这不是预期或授权的。

MAC的设计旨在通过引入更加集中和严格的访问控制机制来解决这个问题。在MAC系统中，访问控制策略不仅仅依赖于对象所有者的自行决定。相反，可信任的权威，如操作系统或安全管理员，根据预定义的规则和标签来定义和执行访问控制策略。

这些策略通常基于对象的分类或敏感性以及主体的准入级别。根据这些标签和策略的评估，决定是否授予或拒绝访问权限，以确保信息流受到控制和授权。

通过实施MAC，组织可以强制执行更严格的访问控制措施，防止DAC系统中可能出现的意外信息流。MAC提供了对访问权限的更加精细和集中的控制，降低了因DAC实施不当而带来的风险。

总之，MAC通过引入集中的访问控制机制来解决DAC系统中的意外信息流问题，该机制强制执行基于对象分类和主体准入级别的预定义策略和规则。这有助于确保对信息访问的适当控制和授权，以减轻未经授权的信息流所带来的风险。

DAC的弱点是由于主体与权限持有者之间存在差距所致

• 请求：一个主体希望执行某个操作
  • 例如，在操作系统中的进程
• 策略：每个授权主体都有一组权限
  • 例如，在操作系统中的用户帐户
• 在主体和授权主体之间填补差距是具有挑战性的
  • 使主体与授权主体之间产生关联

TIP

我们总结以下上述分析。 一方面，在请求中，主体希望执行某个操作。 另一方面，在策略中，权限是授予授权主体的。 为了决定是否允许请求，我们必须填补请求中的主体与策略中的授权主体之间的差距。具体而言，我们需要将主体与授权主体相关联，以便根据策略确定主体是否具有执行操作的权限。

Unix DAC Revisited (1)

• When the Goodie process issues a request, what principal(s) is/are responsible for the request?
• Under what assumption, it is correct to say that User A is responsible for the request?
• Assumption: Programs are benign, i.e., they only do what they are told to do.

TIP

Both User A and User B

对Unix系统中DAC的重新审视(1)

• 当Goodie进程发出一个请求时，什么主体对该请求负责？
• 在什么假设下，说用户A对该请求负责是正确的？
• 假设： 程序是良性的，也就是说，它们只会执行被告知要做的事情。

::tip 用户A和用户B都是 :::

对Unix系统中DAC的重新审视(2)

• 当AcroBat进程（在读取文件后）发出一个请求时，哪个（些）授权主体对该请求负责？
• 在什么假设下，说用户A对该请求负责是正确的？
• 假设： 程序是正确的，也就是说，它们能正确地处理输入。

为什么DAC是易受攻击的？

• DAC包含隐含的假设
  • 软件是良性的，即按照预期的行为
  • 软件是正确的，即没有错误
• 而现实情况是：
  • 恶意软件很常见
  • 软件容易受到攻击
• 问题并不是由政策规范的自由裁量性引起的
  • 指的是所有者可以为文件设置策略

“问题不是由政策规范的自由裁量性引起的！”指的是DAC的漏洞并不是因为所有者可以自由设置文件或资源的策略而固有的。DAC的自由裁量性质，即所有者可以决定访问权和权限，并不是系统中的弱点和漏洞的根本原因。

DAC的问题在于其他方面，例如对软件行为和正确性的隐含假设，恶意软件和软件漏洞的存在，以及在捕获进程的起源方面的局限性。它表明，简单地改变政策规范的自由裁量性质（即所有者可以设置政策），并不能解决DAC的根本弱点。

从本质上讲，DAC的自由裁量性质本身并不是问题所在。相反，是对某些假设的依赖，恶意软件的存在，以及缺乏全面的执行机制，导致了DAC的脆弱性。

TIP

根据以上分析，识别发起者为程序调用者，DAC实际上做出了两个隐含的假设。 首先，它假设所有软件都是良性的。所有软件都按照预期的功能工作，不执行任何恶意活动。 其次，它假设软件是正确的。特别是，输入提供者不能将恶意代码注入程序中。 然而，这些假设在现实世界中是不成立的。事实是，恶意软件很常见，而且软件往往容易受到攻击。

• 执行机制中的更深层次原因
  • 一个单独的调用者不足以捕捉一个进程的来源
• 当程序是木马程序时
  • 应该将程序提供者视为请求的负责方
• 当程序容易受到攻击时
  • 它可能被输入提供者利用
  • 请求可能由输入提供者注入的代码发出
• 解决方案：将输入提供者作为主体之一

TIP

导致DAC容易受到攻击的根本原因是，一个单独的调用者无法捕捉一个进程的来源。 当程序是木马程序时，应该将程序提供者视为发出请求的责任方。 当程序存在漏洞时，它可能会受到输入提供者的攻击。请求可能由输入提供者注入的代码发出。 要解决DAC中的弱点，我们需要在识别来源时考虑程序提供者和输入提供者。

让我们考虑一个例子来说明在识别一个进程的起源时需要考虑程序提供者和输入提供者。

假设我们有一个文件共享应用程序，用户可以上传和下载文件。每个用户都有他们自己的文件集，他们可以对他们的文件设置权限，以控制谁可以访问它们。在这种情况下，用户是所有者，可以为他们的文件设置策略（这是符合DAC的）。

现在，让我们考虑以下几种情况：

木马程序： 用户A上传了一个程序到文件共享应用程序。用户A不知道该程序含有恶意代码，在被其他用户执行时，会执行未经授权的操作。当另一个用户，即用户B，下载并执行该程序时，恶意代码开始执行并非用户B意图的行动。在这种情况下，程序提供者（用户A）应该对程序发出的请求负责。单纯的DAC可能不足以将这些行动归于正确的来源。

易受攻击的程序： 用户A上传了一个有漏洞的程序，例如缓冲区溢出。当另一个用户，即用户B，与该程序互动并提供特定的输入，他们可以利用该漏洞并将恶意代码注入到程序的执行中。在这种情况下，输入提供者（用户B）成为识别请求来源的一个重要因素。单纯的DAC可能无法捕捉到注入代码的来源。

在这两种情况下，仅靠DAC是不足以将请求或行动归于正确的来源的。为了解决这些漏洞，建议的解决方案是将输入提供者作为授权主体，并在识别进程的来源时考虑程序提供者。通过扩大授权主体的范围，包括那些提供输入的人（输入提供者）和那些提供程序的人（程序提供者），就有可能更准确地分配责任并将行动归于适当的来源。