安全性
新 ACL 改进 Windows Vista 的安全性
Jesper Johansson
概览:
- ACL 的新功能
- 更严格的管理员控制
- 可信的安装程序权限
- 经过修改的用户和组
访问控制列表 (ACL) 的基本结构并未针对 Windows Vista 做出多大变化，但您需要对许多细小却重要的变动加以注意。某些变动
是必要的，因为在 Windows® XP 中，ACL 牵涉到了若干问题。首先，大多数 Windows XP 用户都是以管理员身份运行的。也就是说，他们使用的帐户是内置 Administrators 组的成员。对家庭用户来说，这几乎是铁定的，因为在安装过程中创建的所有帐户都会成为管理员。因此，这类用户执行的任何程序也会在执行时享有管理特权，从而可以自由访问操作系统。当然，如果这些程序属于不怀好意的软件，那么问题将尤其严重。
第二个需要解决的问题是，Windows 早期版本中的默认 ACL 令许多人感到不安，因为它们包括了针对 Everyone、Power User 等的 ACL 项 (ACE)。例如，位于 Windows XP 引导卷根目录（通常为 C:\）的默认 ACL 给予 Everyone 读取权限，而且为 Users 组成员授予创建文件夹的权限。最后，Windows XP 对可通过 ACL 进行的操作设定了限制。例如，在 Windows XP 中，绝对无法向某个对象的当前所有者分配权限。您可以将权限授予所有者，但一旦所有者发生变化，那些权限不会随之转移。同样，无论所有者分配到有关对象的何种权限，他们对于该对象始终拥有隐式权限。
在 Windows Vista™ 中，Microsoft 启动了一个新的项目来解决许多这类问题，并启用了对其他功能的支持，比如用户帐户控制 (UAC)。本文着重讲述与 Windows Vista 中的访问控制有关的主要变动。下个月，我将继续探讨您可以用来访问控制的工具上。
新的和经过修改的用户和组
Windows Vista 中有些用户和组是全新的，而有些 Windows XP 中的老面孔已被删除了。此外，有些用户和组的工作方式也得到了修改。每一种变动都对您管理服务控制的方式有所影响。
Administrator — 默认情况下禁用 内置 Administrator 帐户 — 相对标识符 (RID) 为 500 — 现在在大多数情况下为默认禁用。Administrator 的初衷为一种应急帐户，在其他所有办法失败时用以抢救计算机。不过，在过去很多情况下，它作为标准管理帐户被加以使用，并因此违反了安全性的多条原则。这些违规中最值得注意的一条是责任性，它意味着您无法跟踪更改您系统的人。因此，该帐户被部分弃用。最终，Microsoft 可能会彻底弃用该帐户，但现在它在默认情况下是禁用的。如果您在 Administrators 组中没有其他的本地帐户，RID 500 在恢复控制台和安全模式中仍可用，但在其他情况下，您无法，而且也不应使用它。
请注意，内置 Administrator 帐户与 Administrators 组的其他帐户有一个区别。我们通常将“Administrator”的首字母大写以专指具有 RID 500 的帐户，从而将其同“管理员”区分开来，后者是作为内置 Administrators 组一员的任意帐户。组名也以类似的方式进行了首字母大写。
在 Windows XP 中，内置 Administrator 帐户拥有其他管理员所不具备的许多特殊权限和特权。在 Windows Vista 中已经删除了其中许多权限和特权，但有两个值得注意的例外：第一，如果没有其他本地管理员，已禁用的 Administrator 帐户可以在恢复控制台中使用。第二，该 Administrator 不受 UAC 约束，并将一直具有完全管理令牌。同样，域管理员（域中的 RID 500）也是如此。
Power Users 权限已删除 从所有实际用途的角度来考虑，Power Users 组已被废除。该组仍然存在，但授予其的大部分权限已被删除。在过去，Power Users 的成员实际上就是管理员，只是尚未把自己提升为管理员而已 — 这几乎不是个秘密。我曾经在一台安装了所有修补程序，并且运行 Windows XP Service Pack 2 (SP2) 的计算机上，花了不到 45 分钟时间给自己授予了管理特权，从而获得了对该计算机的控制。整个过程包括初步考察、用 C++ 写一个小程序、注销，然后再登录以完成对机器的控制，这一切的实现都因为我是 Power Users 的成员。
许多组织都向 Power Users 组授予复杂的权限，并将其用户加入该组，所以在 Windows Vista 中删除该组是不可行的。但是，Microsoft 很可能在 Windows 的下一版本中彻底删除 Power Users。所以，强烈建议您着手计划从 Power Users 中迁移出去。
可信的安装程序 可信的安装程序实际上是一种服务，而不是用户，即使您会发现，在整个文件系统中，它获得了许多授权。服务加强允许将每个服务视为一个完整的安全主体，可以像对待其他任何用户一样向其分配权限。关于此功能的概述，请参阅*《TechNet 杂志》*2007 年一月期刊。“Windows Vista Security”（Windows Vista 安全性）（Grimes 和 Johansson，Wiley Press，2007）一书详细探讨了服务加强，包括其他功能（如防火墙和 IPsec）如何对它加以利用。
Service SID 不由我们曾经看到的机构（如 NT AUTHORITY 或域）发放。TrustedInstaller 虚拟帐户的全名是 NT SERVICE\TrustedInstaller，它的 SID 是：
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
如图 1 所示，通过运行 sc showsid 命令，您可以查看任何服务的 SID，甚至是那些并不存在的服务。
图 1** sc showsid 会显示任何服务的 SID，包括那些尚不存在的服务 **(单击该图像获得较大视图)
此 SID 以 S-1-5-80 开头。请注意，此处的首个子颁发机构是 80，代表 SECURITY_SERVICE_ID_BASE_RID，意味着此 SID 是由 NT SERVICE 子颁发机构发放给某个服务的。任何服务均是如此。剩余的子颁发机构和 RID 以服务名称本身为基础。这使得开发人员可以为其服务授权而无需先真正构建并安装该服务，因为服务名称是确定的，不会随计算机而变化。
万一您无法在服务管理器中找到 TrustedInstaller 服务，它的显示名为“Windows 模块安装程序”。
Help 和 Support 帐户已删除 在全新安装的 Windows Vista 中，Support_xxxxxx 和 HelpAssistant 帐户均已删除；但是如果从先前版本的 Windows 进行升级，它们将被保留。Support_xxxxxx 帐户曾用于从支持中心运行脚本。有些自己提供帮助内容的 OEM 可能也提供了自己的支持帐户。OEM 帐户未来如何尚不确定，但 OEM 很可能将干脆停止创建它们。严格说来，它们不再是必需的了。实际上，从安全性的角度看，允许用户作为另一个用户从帮助中心执行脚本毕竟不是什么好主意，所以让这些帐户消失是最好不过的。Windows Vista 有一个新的机制来完成此任务。
HelpAssistant 帐户曾在远程帮助中得以使用。就像帮助中心一样，远程帮助功能已经过重新设计，以避免对 HelpAssistant 帐户的需求，该帐户也因此被删除。
新的网络位置 SID 基于 Windows NT® 的操作系统一直都有一些基于网络位置的 SID，比如 NETWORK 和 INTERACTIVE，表示从网络登录以及交互登录的用户。还有一个 REMOTE INTERACTIVE LOGON SID，分配给通过终端服务登录的用户。（注：终端服务用户在其令牌中既有 REMOTE INTERACTIVE LOGON，又有 INTERACTIVE LOGON。）在 Windows Vista 中又添加了另外两个：DIALUP 和 INTERNET。添加一个表示拨号登录的帐户的具体原因还不太明确（尤其是，如果可用的网络只是电话线，不会有越来越多的用户上网的），但此帐户确实存在。INTERNET 显然是指从局域网之外登录的任何用户。但是，NETWORK 仍然是指从网络（包括 Internet）登录的任何用户。
OWNER RIGHTS 和所有者权限 现在有一个 SID 是针对 OWNER RIGHTS 的，它适用于访问某文件而又恰好拥有该文件的任何人。它主要用于限制用户可对该文件进行的操作。与 Windows XP 相比，所有者权限的运作方式有两个显著的变化。第一，如果您是对象的所有者，但对象上有一个适用于您的 ACE，那么该 ACE 中的权限将取代您是所有者这一事实。这是一个重要变动，而且将在很大程度上影响系统管理的某些方面，因为我们都习惯了所有者拥有隐式权限。第二，OWNER RIGHTS SID 能用来进一步限制用户可对对象进行的操作。
假设有一个文件夹，所有者是用户 Jesper，其 ACL 如图 2 中所示。虽然用户 Jesper 是所有者，但他对该文件夹只有读取权限。如果他试图将一个文件复制到该文件夹中，复制将失败，因为他没有该文件夹的写入权限。不过，这一点在错误消息中体现得并不十分直观。如果您试图将一个文件复制到您拥有的某文件夹中，但不具有使用 Windows Explorer® 时的写入权限，则将发生下列情况：首先，Explorer 提示您需要提升权限才能复制该文件，并要求您进行提升，但文件复制失败的原因是您无权将任何文件复制到此文件夹中。您将收到一条错误消息，内容是“您需要权限才能执行此操作”，还有“重试”（好像这能起什么作用似的）和“取消”两个按钮。尽管您是所有者，这种情况照样发生。
图 2** 只有“本地系统”和另一个用户才能够访问此文件夹 **(单击该图像获得较大视图)
如果 Jesper 试图更改文件上的 ACL，系统将提示他提升令牌以进行该操作。由于他是文件所有者，所以他可以这样做。所有者保有隐式读取并更改 ACL（READ_CONTROL 和 WRITE_DAC）的权限，除非某 OWNER RIGHTS 的 ACE 对其另有规定。
要了解 OWNER RIGHTS SID 的效果，让我们将其加入上面的 ACL 中。我们现在拥有的权限如图 3 中所示。
图 3** 向文件夹中添加 OWNER RIGHTS 权限改变了 Jesper 的权限 **(单击该图像获得较大视图)
拥有这些权限后，如果 Jesper 帐户试图往文件夹中复制一些东西，该操作会立刻成功，因为 Jesper 是所有者而且拥有适当的权限。但是，如果 Jesper 试图更改对象上的 ACL，该操作会失败！OWNER RIGHTS 的 ACE 指定所有者仅有修改权限，而无法修改自由访问控制列表 (DACL)。因此，OWNER RIGHTS 主要用以删除所有者的 WRITE_DAC，即修改安全描述符的能力。
如果管理员更改了对象的所有者，OWNER RIGHTS 权限不会自动转移到新的所有者。在这种情况下，OWNER RIGHTS ACE 被禁用，它将标记为仅继承但不应用于容器或对象 — 换句话说，根本不将其应用到任何地方。这样做是为了确保管理员不会完全被该对象拒于门外。要使 OWNER RIGHTS ACE 重新发挥作用，Administrator 必须介入并手动重新启用 ACE。为此，您根据需要将其标记为应用于此文件夹、子文件夹和文件。
OWNER RIGHTS SID 可以在几个有意思的情况下发挥作用，比如当管理员希望用户能在文件服务器上创建文件和文件夹，但又不希望他们能更改这些文件夹上的 ACL 时。另一个可能的情形是用户曾经是某组的成员并创建了一些对象，但后来可能出于商业原因，他们从此组中被删除了。这时，他们应无法修改这些对象上的设置。
OWNER RIGHTS 在服务加强中使用的相当广泛。如果某服务在运行时创建一个临时对象，该对象的创建者是服务进程的主 SID，通常为 LocalSystem，NetworkService 或 LocalService，而不是服务本身的 SID。这意味着，在同一进程环境中运行的其他任何服务都能修改该对象 — 这当然不是人们想要的。通过在这些对象上设置一个 OWNER RIGHTS SID，操作系统能防止其他服务访问它们。
默认 ACL
Windows XP 中的默认 ACL 其实相当不错。除了一些小问题（比如允许用户将文件放在引导卷的根目录下），它们总体来说是有实际意义的。但是，一些 OEM 显然认为他们更清楚合理的安全性由什么构成。图 4 中的屏幕显示了某计算机 Windows 目录上的 ACL 图片，该计算机运行来自一家主要 OEM 的 Windows XP Media Center Edition。该 OEM 实质上禁用了文件系统安全性。
图 4** 一个经 OEM 配置的 ACL **
Microsoft 在 Windows Vista 中对 ACL 进行了一些调整。首先，如果您熟悉 Windows XP，您会知道所有的操作系统文件均由 Administrators 组所有，而且管理员对这些文件拥有完全控制。作为该组的一员，您可以不受限制地访问这些文件。在 Windows Vista 中则不然。
可信的安装程序 在 Windows Vista 中，大多数操作系统文件由 TrustedInstaller SID 所有，而且只有该 SID 才对这些文件具有完全控制。这是加入 Windows Vista 的系统完整性工程的一部分，其目的专门在于防止作为管理员或“本地系统”运行的进程自动替换这些文件。因此，要删除操作系统文件，您需要获得该文件的所有权，然后对其添加一个允许您删除它的 ACE。这提供了一种保护薄层，以防范作为 LocalSystem 运行并拥有 System 完整性标签的进程；具有较低完整性的进程不应具有提升自己以更改所有权的能力。例如，有些服务虽然作为“本地系统”运行，但它们运行时的完整性却为中级。此类服务无法替换系统文件，所以试图接管某个系统文件的操作将无法替换操作系统文件，这稍微增加了在系统上安装 rootkit 或其他恶意软件的难度。同样，如果系统管理员对某些系统二进制文件的存在感到不愉快，要删除这些二进制文件，难度也增加了。
Deny ACE 您会发现，文件系统中的许多对象都有针对 Everyone 的 Deny ACE，这使许多管理员感到惊愕。如果您打开“显示隐藏文件选项”，您会看到熟悉的“Documents and Settings”目录。但如果您单击它，则会收到“拒绝访问”错误。要了解“Documents and Settings”发生了什么，请查看图 5 中的目录列表。
图 5** “Documents and Settings”是一个交接点，而非目录 **(单击该图像获得较大视图)
“Documents and Settings”实际上根本不是目录 — 它是一个交接点！请记住，交接点类似于符号链接，只是将访问重定向到别处。在本例中，交接点指向名为 C:\Users 的目录。Microsoft 在 Windows Vista 中大幅修改了文件系统命名空间，用户数据现在已移至 C:\Users。位于旧“C:\Documents and Settings\<Username>”命名空间之下的其他元素都已迁移。例如，“C:\Documents and Settings\<Username>\Application Data”已移至 C:\Users\<username>\appdata\roaming。如果您转至命令行并使用 dir /a 命令（就像我在图 5 中所做的），您可以清楚地看到这些变化。命名空间发生如此巨大变化的原因是为了使它对于用户更加直观，并更清晰地分隔文档和数据。开发人员现在可以在用户配置文件下创建自己的文件夹（而不用将所有数据文件存储在“我的文档”文件夹中），然后用户会在那里看到它们。所有用户的应用程序数据现在进入了名为 %systemroot%\ProgramData 的隐藏文件夹，而不再位于 Documents and Settings\All Users\Application Data 下。
Microsoft 未删除“C:\Documents and Settings”命名空间，因为早期的应用程序可能已经硬编码为使用该名称，而不是首选的环境变量，比如 %USERPROFILE%。如果“C:\Documents and Settings”消失，这些应用程序将崩溃。作为一种替代方法，它们现在以交接点或符号链接的形式出现，以实现向后兼容。对这些路径进行硬编码的应用程序可能仍会崩溃，这取决于它们访问数据的方式，不过这些应用程序在非英语版本的 Windows 上已经错误百出。这是相当关键的。如果对 Windows（如 Windows XP SP2 或 Windows Vista）更新使第三方程序崩溃，这通常几乎都是因为这些程序的开发人员进行了无效的假设或以不恰当的方式使用了 Windows。
例如，如果您试图通过键入“C:\Documents and Settings\<Username>\My Documents\foo.txt”打开文件（假设您在该位置拥有一个名为 foo.txt 的文件），该文件将被打开。但是，如果您试图浏览至“C:\Documents and Settings\<Username>\My Documents”，您会收到“拒绝访问”的错误消息。要了解发生的具体情况，请查看图 6 中的 ACL。
图 6** “Documents and Settings”上有一个拒绝 ACE **(单击该图像获得较大视图)
请看列表中的第一个 ACE。这是一个针对 Everyone 列出文件夹内容的 Deny ACE。由于 Everyone 具有“绕过遍历检查”特权（也称为 SeChangeNotifyPrivilege），因此程序可以遍历交接点并通过绝对路径打开文档。由于拒绝 ACE 的存在，用户或进程将无法枚举交接点代表的目录。这就是为什么您无法查看 C:\Documents and Settings 的内容而且也无法删除“目录”的原因。将 Deny ACE 放置于此的主要目的就是防止用户删除交接点和破坏早期的应用程序。它同时还提醒开发人员不要使用旧的命名空间来对应用程序编码，而应开始使用环境变量或注册字符串以防止应用程序受未来变化和语言差异的影响。
请注意，所有这些交接点在默认情况下都是隐藏的，因此绝大多数用户永远不会看到它们。为了防止那些能看到交接点的用户将其删除，Microsoft 放入了一个针对“列出文件夹”的 Deny ACE。
绕过遍历检查 用户能够访问其无权访问的文件夹（或交接点）中有权访问的文件，原因在于每个人都有“绕过遍历检查”特权。绕过遍历检查，或 SeChangeNotifyPrivilege，实际上是 Windows 中最基本的特权，它被授予其他所有特权均已删除的进程，除非该进程也特别要求删除该特权。如果您在 Windows Vista 中使用 runas /trustlevel:0x10000 < 命令行来启动一个进程，就会发生这种情况。<command> 中指定的程序将使用一个受限的令牌运行，除了 SeChangeNotifyPrivilege 之外的所有特权都将从该进程令牌中去除。
有趣的一点是，trustlevel 0x20000 给予您具有一组正常 SID 却去除了特权的令牌。而 0x40000 可给予您完全正常的令牌。
默认权限
Windows Vista 文件系统上的默认权限相对于 Windows XP 稍有变化。如果您查看 Windows XP 或 Windows Server® 2003 中 %systemdrive%（通常为 C: 驱动器，即引导卷）上的 ACL，您会看到这些变化（或者与 Windows XP 早期版本上类似的一些内容）：
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
这是 Windows Vista 中同一目录上的同一 ACL：
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
有许多差异值得注意。首先，现在有两个针对 BA (BUILTIN\Administrators) 的 ACE，而不仅仅是一个。但是其实际效果是相同的。在 Windows Vista 中，一个 ACE 是非继承的，并授予对根目录的完全访问权限，另一个 ACE 是 IO（仅继承）ACE，由容器和对象继承，并授予 GA（Generic All 或完全控制）权限。如果用 Windows Vista 中的两个 ACE 来替代一个 SY (LocalSystem) 的 ACE，情况也会如此。在 Windows XP 中，单个 ACE 已被授予完全访问权限，并由对象和容器继承。同样，此处没有什么实际变化。ACL 发生变动的主要原因是为了将特权加以明确和中断，从而使 ACL 更易于管理，甚至还可能更易于恢复。
更有意思的是，针对 CO（创建者/所有者）的 ACE 消失了。这意味着，如果用户在文件系统的根目录创建一个对象，创建者则会因此不再获得特殊权限。
您也会发现，针对 WD (Everyone) 的 ACE 也被删除了。虽然许多曾对安全性感兴趣的人可能不完全了解自己的操作有什么含义，但他们却对该 ACE 都表示了高度的关心。Microsoft 曾花多年时间试图说明，Everyone 在功能上与内置 Users 完全一样，却没有成功；看来，他们最终放弃了尝试并彻底删除了该 ACE。由于存在同样针对 BU (BUILTIN\Users) 的 ACE，而且也被容器和对象继承，所以其实际效果未发生任何变化。
此外，两个针对 BU（内置 Users）的 ACE 已由针对 AU (Authenticated Users) 的 ACE 所取代。原因在于，Guest 帐户是内置 Users 的成员（由于 INTERACTIVE 是内置 Users 的成员），但 Guest 不是 Authenticated Users 的成员。为了允许 Guest 帐户能读取并执行文件，0x1200a9（实际为读取和执行）ACE 将继续授予给 BU。但是，授权创建文件和文件夹的 ACE 却授予了 Authenticated Users。这是与 Windows XP 的差异。在 Windows XP 中，Guest 可在根目录中创建文件。在 Windows Vista 中，Guest 无法创建这样的文件。但是请记住，除非启用 Guest 帐户，而且游客能设法访问引导卷的根目录，否则这些都没有实际意义。默认情况下，Guest 帐户是禁用的。
最好的在后面，在上面的两个列表中有一些非常有意思却看似麻烦的 ACE。在 Windows XP 中，有一个可以由容器继承的 ACE，为内置 Users 指定了 0x100004。由于该 ACE 由容器继承，因此它授权 Users 可以创建子文件夹、子子文件夹等等。还有一个仅继承 ACE，由 0x100002 的子文件夹继承。该 ACE 授权用户可以在其于根目录下创建的文件夹中创建文件和子文件夹。换句话说，这两个 ACE 允许用户，包括 Guest，在根目录下创建文件和文件夹，就像我之前所提到的那样。
在 Windows Vista 中，对应的 ACE 是一个仅继承 ACE，由容器和文件继承，授予 GR（一般性读）、GX（一般性执行）和附带 SD（读取安全描述符）的 GW（一般性写），以及一个仅适用于授予 LC 权限的根目录本身的 ACE。LC 实际上是一个属于 Active Directory® 中 ACE 的快捷方式术语。在 Active Directory 中，它表示用户可以列出子对象。但是，LC 的十六进制值是 0x4。对于目录来说，0x4 代表 FILE_ ADD_SUBDIRECTORY，它在功能上与 0x100004 相同，因为我们已经具有了来自 0x1200a9 ACE 的 0x100000（使用对象以实现同步的能力）。换句话说，它提供了与 Windows XP 中一样的效果，即用户可以在根目录下创建子目录。
十六进制值来自何处？十六进制值最初是什么？正如您已经注意到的，访问控制充满了十六进制（基数为 16）数字，比如 0x1200a9。这些实际上是对设置为“开启”的访问掩码中比特的比特掩码表示，代表它们在此特定的 ACE 中使用。当您使用工具（如 icacls、sc 或 secedit）来列出 ACL 时，如果存在 1:1 匹配，那么比特掩码由更加友好的文本字符串表示。
因此，要确定 LC 的意义，您所要做的就是访问 MSDN® 网站，查找字符串 LC，并在访问权限值栏中查找 ADS_RIGHT_ACTRL_DS_LIST。如果您随后打开 Iads.h 头文件并查找该字符串，您会发现它与 0x4 对应。对于非 Active Directory 字符串（不以“ADS_RIGHT”开头的），您通常会在 AccCtrl.h 中找到该十六进制值。一旦您有了该十六进制值，要在 WinNt.h 或 AccCtrl.h 的访问掩码中查询它的真正含义就变得简单了。
如果您在这方面需要一些帮助，您可能需要一本书，书名为“Protect Your Windows Network”（保护您的 Windows 网络）（作者：Jesper Johansson 和 Steve Riley，Addison-Wesley，2005）。书中的第 17 章深入探讨了如何分析安全性描述定义语言 (SDDL) 字符串和 ACE。
授予这些子目录的权限完全由 Windows Vista 中的 (A;OICIIO;SDGXGWGR;;;AU) ACE 控制，这是 Windows Vista 和 Windows XP 之间的最大差异。Windows Vista 将修改特权授予通过身份验证的用户，而不是像在 Windows XP 中那样，将完全控制授予子目录的创建者。
这个新 ACL 的实际结果是，对象的创建者不再拥有任何特殊权限，情况也变得较为清晰。可能最大的变化在于 Authenticated Users 甚至对管理员创建的子文件夹有了修改权限，这与 Windows XP 非常不同。在 Windows XP 中，Users 和 Authenticated Users 对管理员在根目录下创建的对象不拥有权限。但是，总的说来，虽然这些 ACE 可能看起来有些麻烦，但其实际结果与 Windows XP 的差异并不十分巨大。
总而言之，在 Windows Vista 中，所有人（包括 Guest 用户）都能读取和执行根目录下的文件。只有通过身份验证的用户才能创建新文件和文件夹，而且他们创建新文件和文件夹的同时会获得这些文件和文件夹的修改权限。换句话说，尽管在默认情况下禁用 Guest 帐户值得注意，但 Windows Vista 上的权限严格性比 Windows XP 高不了多少。
令牌的变化
在 Windows XP 中，当属于 Administrators 组成员的某个用户登录时，他的令牌包括 Administrators 组 SID，而且他可以执行任何 Administrator 组可执行的操作。另一方面，在 Windows Vista 中，情况由于用户帐户控制而发生了变化。Administrator SID 仍然存在于令牌中，但已设置为仅拒绝，如图 7 的 Process Explorer 屏幕快照所示。
图 7** 在 UAC 下，除非您提升权限，否则 Administrators SID 仅用于拒绝访问 **(单击该图像获得较大视图)
当执行访问控制时，令牌中的这一项仅用于拒绝访问，也就是说，用于匹配 DENY ACE。任何针对该 SID 的允许 ACE 都被忽略。这意味着即使您以管理员身份登录，您也不一定一直是真正的管理员。
完整性级别
Windows 现在支持用完整性级别标记进程和对象。这些完整性级别实际上也由 ACE 体现，但不在 DACL 中。相反，它们是系统访问控制列表 (SACL) 的一部分，具有一些特殊标志。例如，标志 NW 用于表示阻止较低完整性级别的进程写入较高完整性级别的对象 (SDDL_NO_WRITE_UP)。在本期*《TechNet 杂志》*中，Mark Russinovich 在其文章“Inside Windows Vista User Account Control”（深入了解 Windows Vista 用户帐户控制）中详细阐述了这一内容。
总结
虽然在 Windows Vista 中对于访问控制的修改不像 Windows 2000 中那样翻天覆地，小的改动却有很多。单个看来，它们好像不是很重要，但作为整体考虑时，它们意味着您在管理系统时需要重新思考许多操作。此外，这些变化支持许多其他首创功能，特别是 UAC 和服务加强。有些管理员在刚开始使用 Windows Vista 时可能会感到很沮丧。我已经看到一些评论，说“专横的操作系统”限制了删除操作系统组件的能力 — 这些组件出于这样或那样的原因令人感到不快。但是，所有这些变化的出现都有充足的理由，而且，如果您花些时间分析变化的内容，就会理解其中的原因。
Jesper Johansson是一家大型电子商务公司的安全架构师，专门负责涵盖所有属性和服务种类的应用程序安全策略。他在安全性领域工作了 20 年，撰写了许多关于安全性的文章并出版了两本著作。在信息安全工作领域之外，他是名潜水教练。
© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.