本文将介绍以下内容：
访问控制列表
用户权利
文件系统权限
注册表及其权限
本文使用了以下技术：
Windows Server 2008
对象安全描述符
理解安全描述符 string_aces
标准权利和特定权利
完整性标签及其用法
Object_guid 和 inherit_object_guid
解释安全描述符 string_aces
Windows 资源保护
设置安全文件系统权限
管理注册表及其权限
总结
只要系统中有所动作，主体（可以是代表用户或服务执行操作的进程或线程）都会在对象上执行一些操作。比较常见的对象有文件、目录和注册表项。Windows 的基本安全机制包括使用可信的系统组件在执行操作之前检查权限和权利 (AccessCheck)。因此，可以通过设置权限和权利管理系统行为。因为在尚未理解权限和权利工作原理的情况下可能无法正确设置权限，所以我将首先介绍对象的安全设置及其处理方式，然后介绍如何为它们设置值。
图 1 本地磁盘 C 的用户权限
图 2 C 盘的用户权限高级视图
用户组的成员可以在系统驱动器根目录下创建文件夹并向文件添加数据。如果单击“编辑”按钮，您将看到另一项对子文件夹的“特殊”授权，如图 3 所示。此操作需要管理员权限。
图 3 用户特殊权利的编辑视图
您可以看到在 Windows Server 2008 中，普通用户默认可以在系统驱动器的根目录创建子文件夹，并向这些文件夹添加内容。为 Windows Server 2008 中用户组的成员提供该功能的原因是某些第三方软件假定存在这些权限，而 Microsoft 不想破坏应用程序的兼容性。
现在让我们开始讨论这些问题涉及的技术，并了解这些权限在用户所能看见的 GUI 界面之下的工作原理。在 Windows 中所有命名的对象都具有安全描述符，它提供有关其所有者的信息，并列出哪些用户和主体具有特定权限。描述符还可以指定必须在系统事件日志中记录哪些对象访问权限。
请注意：Windows 还支持针对对象的系统 ACL (SACL)，并已在许多版本中使用 SACL 设置建立了需要记录到审核日志的事件。在 Windows Server 2008 和 Windows Vista 中，SACL 已扩展至能够携带完整性级别信息。
该完整性标签将用于建立“低级”标签，用它标记 LowRights Internet Explorer 中的 Internet Explorer 进程。“系统”和“高级”标签用于保护重要的系统资源。Windows 消息泵可以根据消息的完整性级别过滤消息。例如，中级进程不会接收低级进程发送的消息，而高级进程不会接收来自低级或中级进程的消息。
此时，完整性级别保护起到的是缓解的作用，而不是真正用于安全保护的安全屏障。在后续版本中，随着它逐渐成为真正的安全屏障，它的作用会大大加强。
与其它现代操作系统一样，Windows 依靠 DACL 进行常规访问控制决策。此处我将重点介绍 DACL。系统要决定是否允许某个主体对某个对象执行操作需要检查以下几项内容：主体的权限、主体的令牌，以及对象的安全描述符。对象的二进制安全描述符将随主体的令牌一起传递给 AccessCheck 例程。随后将准备所请求的访问掩码位向量，该向量代表访问权限检查成功所必须具备的访问权利。该向量将随主体的安全描述符一同传递给 AccessCheck 例程，然后由该例程根据所请求的访问和对象的 DACL 检查用户的安全令牌并考量主体权限（通常基于角色或成员关系，例如管理员）。
如果主体的权限满意所请求的访问，则授予访问权限。否则将按顺序检查 DACL 访问控制条目 (ACE)。一旦安全系统能够证明允许所有请求的访问组件或拒绝其中任何请求，它将相应返回成功或失败。
对象安全描述符
虽然安全描述符是二进制数据结构，但它需要依赖安全描述符字符串格式提供便于用户阅读的文本格式。字符串格式的安全描述符是以 null 结尾的字符串，它包含指明以下四个主要组件的令牌：所有者 (O:)、主要组 (G:)、DACL (D:) 和 SACL (S:)，如图 4 所示。
图 4 安全描述符
安全描述符 (SID) 通过结构化提供解析信息，并包含 96 位随机信息（并有可能包含 32 位序列计数器）以作为所有者的唯一标识符。string_aces（以字符串格式表示的 ACE）是 DACL 中显式授予或拒绝权限和 SACL 中设置策略的结构。每个 string_ace 都包含在圆括号当中并采用以下结构：
(ace_type;ace_flags;rights;object_guid;inherit_
object_guid;account_sid)
只有那些正常访问相关对象所必需的权限必须存在。通常，安全描述符将省略 owner_sid 和 group_sid。如果在创建时未明确指定，那么安全描述符的所有者字段将设置为调用对象创建的主体的 SID。组字段设置为主体安全令牌的主要组。如果不需要审核对象或设置完整性标签，则不存在 SACL。
在 string_aces 中，只包含那些必要的字段（最小集合为 ace_type、权利和对象，通常为 account_sid）。一般不包含 object_guid 和 inherit_object_guid。系统将按从前到后的顺序解析 ACE，直到授予或拒绝访问权限为止。因此，ACE 的顺序很重要。“拒绝权限”应该放置在“允许权限”之前。
现在我们有必要看看安全描述符的实际内容。下面是 Windows Server 2008 系统驱动器根目录的安全描述符（请注意 cacls 是用于检查和设置 ACL 的早期命令行例程，现已由 icacls 代替。遗憾的是，icacls 不支持使用命令行开关输出以标准安全描述符定义语言 (SDDL) 表示的结果，在 cacls 中该开关为 /S 标志）：
C:>cacls c:/ /s
c:"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)(A;OICIIO;GA;;;CO)"
根据我们已经了解的有关安全描述符的知识，您可以从开头的“D:”看出尚未声明所有者关系或组成员关系，而且该描述符是 DACL。该 DACL 是受保护的：已经设置了“P”和 Windows NT 5.0 继承标记。随后是一组需要进行解释的 ace_strings。
理解安全描述符 string_aces
回想一下前面讲述的 string_aces 格式。图 5 中定义了有效的 ace_types，图 6 中定义了有效的 ace_flags。用于继承的 ace_flags 是 ACE 继承的决定因素。
图 5 有效的 ace_types
图 6 有效的 ace_flags
图 7 ACL 访问掩码
系统对所有对象使用一种 ACE 权利位图表示。对不同的对象来说，并不是所有的位都有意义。只应用那些适用于某个对象的权利。标准权利是对所有安全对象都通用的权限。泛型权利是为各种对象指定相似类型权利的简便方法。泛型权利的规范映射为一组适当的具体权限集合。当指定 SACL 时，完整性标签也将使用 ACE 权利字段进行编码。图 8 中列出了各种对象的可用权利。
图 8 泛型权利
有许多大致等同的权利映射在使用时并无区别。完全控制 (FC) 等同于 Generic_All (GA)。对于文件系统，File All (FA) 是适用的完全控制声明。Key All (KA) 是适用于注册表的完全控制声明。泛型声明常用于更适合声明的地方，但会根据需要映射为适当的文件系统或注册表项声明。SDDL 表达式常常混合这些术语，因此您需要了解等同的术语。
标准权利和特定权利
许多对象都可以分配权利。除文件和目录外，还有注册表项、进程、桌面等。要查看完整的列表，请参阅图 A 到图 J。我们将会讨论文件系统和注册表的权限，图 9 和图 10 中提供了这些对象的特定权利。
图 9 特定文件权利
完整性标签及其用法
前面提到过，如果存在完整性标签，则它将存储在对象的 SACL 中。对象隐含具有中级完整性，因此如果某个对象没有完整性标签，则它将具备中级完整性。同样地，如果安全令牌没有完整性标签，则它也将具备中级完整性。低级完整性标签用于标记低权利进程，例如低权利 Internet Explorer 及相关的非受信对象。“高级”和“系统”级别用于帮助将这些对象从中级和低级进程和对象中隔离出来。完整性标签如图 11 所示。
图 11 完整性标签
Object_guid 和 inherit_object_guid
Object_guid 和 inherit_object_guid 用于指定 Active Directory 中对象的安全性。不会使用它们来保护文件系统和注册表安全。ACE 字符串内 ace_type 字段中的“OA”和“OD”分别对应于对象允许和对象拒绝 ACE。在本例中，object_guid 持有正在请求权限的对象的 guid，而 inherit_object_guid 持有它所继承权限的那个对象的 guid。
“所有者权利”的 OW 声明是 Windows Server 2008 和 Windows Vista 中新增的声明。在以前版本中，对象的创建者/所有者 (CO) 具有读控制 (RC) 标准权限和对该对象的 Write_DAC (WD) 权限，以便所有者能够设置该对象的安全性。如果用户是某个组的成员并创建了大量对象，这种方法会出现问题。如果该用户离开该组，他可能仍然会拥有对这些对象的控制，因为他是这些对象的所有者，所以可以获得这些对象的 RC 和 Write_DAC 权限。对 OW 所有者的 ACE 限制可以防止向所有者隐性授予 RC/WD 权限，除非在 ACL 中向任何其它相关 ACE 的所有者 ACE 显式授予这些权限。这种方法可以抑制以前版本中的安全隐患。
解释安全描述符 string_aces
对系统驱动器根目录运行 cacls 命令的输出如下：
"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)
(A;OICIIO;GA;;;CO)"
为提高可读性对其进行解析后，结果如下：
"D:PAI
(A;OICI;FA;;;SY)
(A;OICI;FA;;;BA)
(A;OICI;0x1200a9;;;BU)(A;CI;LC;;;BU)(A;CIIO;DC;;;BU)
(A;OICIIO;GA;;;CO)"
内置管理员和系统将得到文件（来自对象继承）和目录（来自容器继承，即 CI）可继承的 File All 权利。这意味着此 DACL 将递归授予根目录下所有文件和目录的 File All 权限—必须检查受保护 DACL 中的授权是唯一的例外，那会禁止继承。CO 将获得根目录下所有文件和目录的 Generic_All 权限（由于仅继承标记），该权限将映射为 File All。
对内置用户的授权更为有趣。第一个 string_ace 将应用到根目录及其子目录中所有的文件和目录，授予 List、Read、ReadEA、Traverse、Execute、ReadAttr、ReadControl 和 Sync 权限。第二个 string_ace 授予在根目录及其子目录中 AddSubDir 的权限（由于 IO—仅继承标志），而第三个 string_ace 授予子目录的 AddFile 权限。这与您使用 Windows 资源管理器的 ACL 图形化界面查看这些权限时看到的一样。
Windows 资源保护
从 Windows Server 2008 和 Windows Vista 开始，组件将在其清单中声明所需的安全设置，该清单将由 Microsoft 代码签名根项进行签名。该清单指定 ACL 及与文件关联的其他权限。因此，当安装某个组件时，它将自带适当的安全设置。此外，系统管理员还可以使用 Windows 资源保护 (WRP) 防止操作系统文件受到意外损坏。WRP 依赖新的系统级别实体 Trusted Installer 拥有并管理系统文件和文件夹。
在 Windows Vista 中还增加了允许普通用户安装授权组件的便利功能。“超级用户”角色将不再需要，因此将删除包含“超级用户”SID 的 ACE 实例。“超级用户”组仍然存在，但会对组件清单进行扫描并删除所有 PU 权限授予实例。
C:>cacls c:windows /s
C:Windows "D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-18310
38044-1853292631-2271478464)(A;CIIO;GA;;;S-1-5-80-956008885-3
418522649-1831038044-1853292631-2271478464)(A;;0x1301bf;;;SY}
(A;OICIIO;GA;;;SY)(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)(A;;0x1200a9;;;BU)
(A;OICIIO;GXGR;;;BU)(A;OICIIO;GA;;;CO)"
“可信的安装程序”的 SID 是 S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464。使用 TI 作为简写，我们可以发现下面的内容：
C:Windows "D:PAI
(A;;FA;;;TI)(A;CIIO;GA;;;TI)
(A;;0x1301bf;;;SY)(A;OICIIO;GA;;;SY)
(A;;0x1301bf;;;BA)(A;OICIIO;GA;;;BA)
(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)
(A;OICIIO;GA;;;CO)"
通过解读，您可以看出这是受保护的 ACE，它使用 Windows NT 5.0 继承模型应用到 C:Windows。
“可信的安装程序”对 C:Windows 具有完全控制权限，并具有 C:Windows 下所有子容器（由于是 CI，仅继承）的 Generic_All 权限。
由于管理员能接管所有权，所以他仍然可以声明 WriteOwnership 权限并在任何情况下取得控制权。管理员和系统在安全方面不相上下。但由于有了该权限，管理员可以绕开 WRP ACL 控制。
CO 还拥有子文件和目录对象的 Generic_All 权限。内置用户拥有对 C:Windows 的 Read、ReadEA、Execute、ReadAttr、RCtl 和 Sync 权限（等于 GRGX 权限），并拥有 C:Windows 下子目录和文件的 GRGX 权限。
所有的系统文件和文件夹都包含受保护的 ACL，它们授予“可信的安装程序”完全控制权限。“可信的安装程序”对文件的控制不在系统根目录的声明中表述，而是在 Windows 组件的单独声明中表述。
设置安全文件系统权限
在了解文件系统 ACL 的工作原理和解读方法之后，让我们看看如何进行设置。如果正在安装某个应用程序，您应该将它安装到默认的 Program Files 位置。该位置的默认 ACL 将为管理员和本地系统提供完全控制权限，这并无不妥。
如果将应用程序安装到其它位置，或者允许用户选择喜欢的位置安装应用程序，那您将会遇到问题：其它驱动器和系统驱动器的非系统及非应用程序区域的默认 ACL 并不十分安全。在这种情况下，您必须使用受保护的适当 DACL 显式控制文件夹的 ACL。安装应用程序最简单安全的方法是复制 Program Files 文件夹的安全设置。如果选择不这么做，那您可以设置 DACL 使非管理员无法更改 DACL 和可执行文件的所有权，并使其无法在包含可执行文件的目录中写入、附加或删除文件。
乍一看似乎任何时候您都不应该允许用户向 Windows、System、Program Files 的文件夹中写入文件。但有许多充分的理由需要执行这类写入操作。最常见的是记录错误日志数据。如果可执行文件在用户凭据下运行并且需要记录错误，那它需要具备错误日志文件夹的写入/附加权限。（如果将错误记录到多用户系统中每个用户的位置，则需要将记录数据传遍整个系统，而不用与可执行文件相关联。应用程序和服务器通常写入共享文件夹或注册表项。）您会在注册表中发现相同的问题，使用用户权限运行的进程经常会把错误信息存储在特定的机器注册表项中。
请不要将用户可写的文件与可执行文件混放在一起。应该使用不同的目录存放必须信任的文件（例如可执行文件）和必须不被信任的文件（例如可能由不受信任的用户编写的任何文件）。为目录设置适当的 ACL—管理员控制可执行文件，而用户可以读取/执行但不能写入。注册表项和子项也适用相同的原则。
客户端和服务器的不同之处在于：服务器管理员假定比管理员用户具备更多的知识。服务器管理员知道他们必须拒绝执行来自系统非受信区域的代码。通过建立命名规范将数据文件与系统中的可执行文件隔离，您可以就可执行文件的可靠性为管理员提供指南—日志子目录并不可信，因此必须禁止用户创建或更改这些子目录，防止他们欺骗安全命名规则。
在很多情况下可能需要用户能够共享数据（尽管我们不希望用户在共享区域共享和执行代码）。例如，家庭用户（或者他的照片查看应用程序）可能会创建类似 C:Photos 这样的目录。该用户希望能够允许多个用户在此目录中写入文件并使其能够编辑该目录中的各种照片。 Windows Vista 中系统驱动器根目录的默认 ACL 支持这种应用。另一种常见的共享情况是用户希望在某个文件夹中放置数据供其它用户读取。只允许数据创建者删除或修改这些数据，但其他用户可以复制数据和编辑副本。这是一种共享读取方案，Windows Server 2008 的系统驱动器默认使用此方案。
现在考虑另外一种情形：您选择锁定系统驱动器，或具体而言，针对共享使用 ACL 设置文件夹。您需要选择适合这两种情况的 ACL，而不是常见方案。我们希望管理员能够管理对象，同时还希望防止因在这些文件夹中执行代码而出现安全问题（请注意：此处的 ACE 甚至会阻止所有者从这些文件夹执行代码）。
以下是共享读取 ACE：
D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;CI;0x1200af;;;AU)(A;OI;GR;;;AU)
以下是协作性 ACE：
D:P(D;OI;WP;;;WD)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;OICI;SDGRGW;;;AU)
对于“共享读取”方案来说，因为此授权在 CI 和目录方面的限制，经过验证的用户将获得 List、AddFile、AddSubDir、ReadEA、Traverse、ReadAttr、RCtl 和 Sync 权限，单独得到对所有文件的 Generic Read 权限。对于“协作”方案来说，经过验证的用户将获得文件和目录的 Delete、Generic Read 和 Generic Write 权限。
管理注册表及其权限
Windows 将许多状态信息存储在 Windows 注册表中。注册表数据以“配置单元”格式存储，数据存储在项和子项当中，可以将二者视为容器（子项不视为对象）。
用户特定数据存储在 Hive Key Users (HKEY_USERS) 的相应用户中。如您所料，这种数据大多可由用户写入。在任何会话内，HKey_Current_User (HKCU) 都将指向 HKEY_USERS 的适当部分。
系统和机器信息存储在 HKEY_LOCAL_MACHINE (HKLM) 配置单元中。HKLM 中包含的是各种系统服务的信息，其中大多数现在均使用本地服务或网络服务组的有限权限运行。服务和应用程序可以在其注册表项中存储状态信息。这些信息应该存储在子项（隶属服务项或服务项包含的项）当中。切勿通过 ACL 处理服务项，使该服务具有对其自身服务项的 SetKey 权限（或者 WDac 或 WOwn 权限，这些权限可能会导致此类攻击），因为这样会使该服务能够指向不同的可执行文件。此类错误可能导致服务主机遭到 EoP 攻击，因为服务控制管理器可能会在系统加载时也加载该服务所指向的可执行文件。
您需要尽力避免的情况是用户修改受信任的参数（例如关闭反病毒或防间谍软件服务）或使用用户或管理员使用的工具篡改数据。假设当调用“记事本”时它会加载 C:windowsnotepad.exe。C:windows 的默认 ACL 不允许攻击者修改此可执行文件。如果攻击者可以重写从“记事本”图标到其可执行文件的链接，则攻击者可以将该图标链接到其他文件（例如 C:toolsload_rootkit.exe）并加载它。这样可以在加载 rootkit 之后再加载“记事本”，从而使用户感觉不到系统已经遭到破坏。
如果攻击者可以通过注册表驱动链接，那文件系统中保护性的 ACL 将起不到多大作用。您还可能受到从受限系统服务向其它系统服务发起的攻击。在 Windows Vista 和 Windows Server 2008 中，服务将按照其所需要的权限划分为不同的组。这种服务隔离技术提供的深度防御保护需要服务权限配置，这样服务（特别是跨服务组的服务）之间将无法互相篡改数据。
正如我们需要考虑防止用户添加或链接到恶意可执行文件一样，我们还必须防止服务更改其权限和功能。服务的 ChangeConf 权限必须限定给管理员、系统或可信的安装程序，因为该权限允许处理器更改服务的权限。
总结
Windows 提供了非常丰富的权限控制功能，它们可用于允许操作、阻止操作并提供对新威胁的深度防御。这一丰富的访问控制功能自然会令加大复杂性。
最重要的指导原则是严禁管理员或系统帐户执行或通过指针指向用户能够写入或修改的代码。同样重要的是用户不能执行或通过指针指向另一个用户能够写入或修改的代码。这些指导原则适合本文中讨论的各种安全问题。如果您所做的更改都遵守这些指导原则，那您将可以避免大多数严重的安全问题。
有关访问控制组件的更多信息，请参阅 MSDN 中的“访问控制组件”。有关 ace_string 访问掩码组件的信息，请参阅 MSDN“ACCESS_MASK”文章，其中包含对文件、目录、注册表项和共享内容特殊权限的介绍。有关受限 SID 的其他信息，请参阅 MSDN“受限令牌”文章。
权利的完整列表
图 A 标准权利
图 B 文件和目录的特定权利
图 C 文件映射和注册表的特定权限
图 D 服务控制管理器和服务的特定权利
图 E 进程和线程的特定权利
图 F WindowStations 和桌面的特定权利
图 G 符号链接和事件的特殊权利
图 H 信号量和互斥体的特定权利
图 I 管道和令牌的特定权利
图 J 通用或公认的帐户及其 SID 字符串
John R. Michener 是 Microsoft 的高级安全项目经理。他在大约 5 年前加入 Microsoft Windows 安全团队。John 拥有 20 多年系统安全方面的经验并曾经三次进行安全领域的创业。他是 Windows 软件保证团队的密码和权限专家。您可以通过 jmichene@microsoft.com 与他联系。
联系客服
