桌面文件让管理员退居幕后

Wes Miller

在三年多以前，我开始将我的主 Windows 系统上的用户帐户从本地管理员帐户转换成了本地用户帐户。我已在 Microsoft 工作了七年多的时间，始终都是以完全权限的 Administrator 身份运行。毋庸置疑，这样做很方便——但是却缺乏安全保障，

我和其他许多人所处的这种状况并非只限 Windows 系统，其他系统也屡见不鲜。

我经常希望有一种方法能够对此进行准确的统计，但我其实很清楚而且业内人士也曾告诉过我，现在有太多的组织甚至 IT 专业人员本人都以本地 Administrator 身份运行。在 Winternals，我切换到以 User 身份运行的前提是了解这样做的困难程度（作为“专业消费者”），并且在一定程度上了解我们的产品 (Winternals Protection Manager) 在一般组织中能提供什么样的帮助。假设大多数组织中的大部分用户至今仍在以 Administrator 身份运行，我们的目标是使管理员能以 User 身份运行，并最大程度减少转换工作（或至少是所带来的麻烦）。无论使用何种技术，将组织中的用户从 Administrator 身份转换为 User 身份并非易事，但这却是减少组织攻击面的最有效方法。它可以被视为系统内的防火墙，因为这也的确是其真正的作用。

应该如何实现呢？

您面临的挑战：感到痛苦

如果您尚未开始考虑将 Administrator 身份转换成 User 身份，那现在是开始考虑的时候了。建议您首先亲自感受一下。不要在备用计算机上——那样不真实。请在您的主系统（即您天天使用的计算机）上进行尝试。如果运行的是 Windows Vista®，还建议在不使用“用户帐户控制”(UAC) 的情况下进行尝试。如果想在组织内宣传进行某些变革，在大张旗鼓进行宣传之前首先自行体会一下是个不错的主意。相信您会发现以非管理员身份运行并非像您想象的那样困难——而且在引入了这样的安全措施后，将会切实改变组织的攻击面。

大多数用户都以 Administrator 身份运行的根源在于 Windows® 的历史。从第一个版本的 Windows 开始，到 Windows NT® 3.1 之前，每个交互式用户的权限都与下一个用户相同——从功能上讲，没有任何安全性可言。在家用环境下，这并不算是个大问题；它意味着所有软件都以相同的方式进行安装。这样做是假定此用户拥有该计算机，并且安装的所有软件都允许该计算机的所有用户使用。

当 Windows NT 首次面市时，它肯定不能立即占领企业（更不用说消费者）市场。并且由于 32 位 Windows 和 Windows NT 之间存在着的 Win32® 兼容性问题，大多数应用程序供应商并没有仅仅为了 Windows NT 的安全性基础结构而重建其应用程序。实际上，直到 Windows 2000，许多面向消费者的“独立软件供应商”(ISV) 才开始注意到 Windows NT。当然，是 Windows XP 强制解决了此问题，因为它终结了 Windows 的 9x 系列。

但是，应用程序仍假定系统中的每个用户均有权写入到 Program Files、注册表中的 HKEY_LOCAL_MACHINE (HKLM) 以及 HKEY_CLASSES_ROOT，而事实却不是如此。在这些假定访问的情形中，游戏常常是最令人头痛的一个方面，请参阅 Matt Clapham 有关此主题的文章，网址为：technetmagazine.com/issues/2007/02/Gaming。

这的确是个问题，因为大多数跨系统应用程序都将其文件和注册表设置存储在这些位置，您需要能够读取和写入这些位置才能安装它们。不幸地是，一些应用程序仍坚持在安装后写入这些注册表项。例如，我女儿有个基于 Flash 的游戏。每次运行时它都会尝试安装一个自定义播放程序——这意味着当我女儿以 User 身份而非 Administrator 身份运行时，应用程序将无法启动，并会出现一个致命错误。尽管这是个极端案例，并且它是一个消费者应用程序，但实际上许多非消费者应用程序在非管理用户方面做的也不够好。事实上，如果您深入探寻我的挑战（请参阅侧栏“您面临的挑战：感到痛苦”），您就会发现 Windows 对以 User 身份运行的支持程度是多么糟糕。

如果看一看图 1，您会了解到在 Windows XP 上以 User 身份运行 IPConfig /release 后产生的效果。如果与图 2 进行比较，您会发现在 Windows Vista 下运行这个命令的效果也好不到哪儿去，但至少可以了解到命令失败的原因。请注意，联网工具整体都得到了改进，可以允许用户刷新其 IP 地址。同样，在任意版本下尝试以 User 身份运行 Computer Management (compmgmt.msc) 都只能执行有限数量的任务——而且通常会产生令人沮丧的结果（如图 3 所示）。尽管 Windows Vista 最初并未启用 Computer Management 中的许多工具，但却比较清楚地给出了访问被拒绝的消息。

Figure 1** Running as a user under Windows XP **(单击该图像获得较大视图)

Figure 2** Running as a user under Windows Vista **(单击该图像获得较大视图)

Figure 3** Misleading message after running compmgmt.msc as a user on Windows XP **(单击该图像获得较大视图)

为什么重要

那么为什么我们要给予关注？因为作为 IT 专业人员，我们应该开始强制应用程序调整到最低权限用户，而非让应用程序假定交互式用户拥有系统。

遗憾地是，对于那些允许管理员写入注册表项的策略，它们也授予了在用户上下文中运行的恶意软件对那些未通过“访问控制列表”(ACL) 明确拒绝的所有内容的完全访问权限。在 UNIX 领域，人们普遍都不以 root（在功能上等同于 Windows 的管理员帐户）身份运行，这主要是因为推动安全模型边界的软件体系几乎已不再存在。

尽管如此，您最好采取同样的做法，仅在明确要求时才以 Administrator 身份运行——或者更进一步，仅以 Administrator 身份运行单个应用程序。这样做之后，即可建立起我之前提到过的系统内防火墙。从而，当恶意软件或间谍软件试图执行其不应执行的操作时将会失败——因为它无法写入注册表或文件系统位置，而不写入这些位置就不能真正感染系统（如安装服务或驱动程序，或者为所有用户安装）。此外，这还可以使反恶意软件程序能够抑制它所识别出的恶意软件，使其不致首先危及整个系统。

但是要注意，这并不能保证用户不受攻击。很可能有一些恶意软件能够成功感染单个用户的上下文或破坏其数据（尽管此类恶意软件目前尚未广泛传播）。但此类软件所针对的攻击目标比较有限。因此，采用 Linux 或 Macintosh 上所采用的恶意软件防御方法（潜在的受害者如果比较少的话，恶意软件作者根本就不屑于去关注）有助于确保您的最终用户以及您自身的安全。

Power User 退出历史舞台？

在开发 Protection Manager 时，我们从客户那里听到过这样一番话：“我们的所有用户都以 Power user 身份而非 Administrator 身份来运行 Windows XP，因此我们是安全的。”可是，实际上 Power user 与 Administrator 之间的差别并不大。Windows XP 中存在很多潜在的漏洞，只需略施小计就可以使 Power user 变为 Administrator。事实上，在 Windows Vista 和 Windows Server® 2008 中已删除了 Power user 组；只有从之前版本的 Windows 升级而来的系统还保留着 Power user 组。总而言之，应尽可能避免使用 Power user 组，即使您使用的是 Windows XP。

权限损耗

如果您读过我在三月份撰写的有关 Windows 瘦客户端的专栏 (technetmagazine.com/issues/2008/03/DesktopFiles)，则应该记得我曾说过使 Windows XP 通过瘦身的方式来节约空间。同样，在将 Administrator 转换成 User 时可以考虑采用一种常见的做法，但执行起来必须要当心。这种做法就是调整注册表和文件系统的 ACL，使用户可写入其通常不能写入的位置——从而允许那些存在此类问题的应用程序访问。

显然，最佳选择是获取更新的应用程序以避免进行这种改动，但有时这是不可能的。如果必须更改权限（即降低它们），操作时要非常谨慎。要记住，User 和 Administrator 之间的防火墙主要是通过注册表和文件系统权限来定义的。打开它会降低保护程度，并可能拓宽呈现给恶意软件的攻击面——因此执行前务必要三思。

UAC 又是怎样的情形呢？

说到将用户从 Administrator 身份转换成 User 身份，就不能不提到 Windows Vista 中的“用户帐户控制”(UAC)。UAC 与 Mac OS X 中的类似功能一样，可以使您在以 Administrator 身份运行时不必面临如此大的风险。

这是如何实现的呢？看一看图 4 中 Process Explorer 显示的有关 cmd.exe 的内容。右侧的 cmd.exe 实例是在未提升的情况下启动的，而且我是以 Administrator 身份运行的。结果，即使右侧的用户与左侧的用户完全相同（左侧的 cmd.exe 是在提升的情况下启动的），应用程序本身并未包含它（以及运行该实例的用户）在执行需要管理权限的任务时所需的权限和令牌。UAC 是通过降低用户交互式上下文中的攻击面来工作的。唯一的问题是必须告诉 Windows：即执行此任务需要管理权限，用户有资格获得完成此任务所需的提升。

Figure 4** Two instances of cmd.exe with different privileges **(单击该图像获得较大视图)

Windows Vista 中的小盾牌显示了哪些任务需要提升（请参见图 5）。这些任务在每次运行时都需要提升——而这也是大家特别关注的 Windows Vista 的弱点之一。替代方法是使凭据更具“粘性”，而这可能会带来潜在的安全威胁，使系统更容易被利用。

Figure 5** Shields in Windows Vista indicate the need for elevation **(单击该图像获得较大视图)

如果启用了 UAC 且用户仅以 User 身份运行，则当应用程序需要管理权限时，系统会提示其提供一组管理凭据。请注意，在此示例中，就像是使用 runas 或 psexec 时一样，应用程序实际是在您启动它时使用的 User 身份的上下文中运行（与在 UAC 下作为管理员不同）。在这种情况下，这些任务以提升的权限在您的上下文中运行。

以 User 身份运行 Windows Vista？

在运行 Windows Vista 时，我个人倾向于使用 User 身份而非 UAC 下的 Administrator 身份，因为我认为在一般的企业中，这仍是最好的想法。毕竟，这样做不但用户可以完全控制其系统，而且您也可以减少受到恶意软件攻击的机会。

此外，如果您打算管理用户（使用组策略）、防病毒软件、反恶意软件程序或其他软件，并希望集中控制这些任务是否实际执行或完成，必须确保最终用户不是管理员。如果用户是管理员，他们可能会停止服务、添加或删除驱动程序等。当然，以 User 身份运行的别有用心的最终用户可以使用 Windows PE 来绕过某些安全屏障。BitLocker® 可增加其难度，但我要重申，只要有充足的时间和丰富的知识，在经过深入钻研后，具有物理访问权限的最终用户将可以对其计算机执行他所希望的任何操作。

以 User 身份运行 Windows Vista 与以 User 身份运行 Windows XP 的差异并不仅限这些。需要时，可以使用相同的工具（PSExec、RunAs 和现在的 UAC）以 Administrator 身份来运行任务。让人高兴的是，许多在 Windows XP 中需要管理权限的任务现在都已不再需要。例如，Windows Vista 用户可以安装本地打印机。（在 Windows XP 中，用户可安装网络打印机，但安装本地打印机需要有管理权限。）在 Windows Vista 中，只要用户实际进入了计算机并且打印机驱动程序位于驱动程序库中，用户就可以安装打印机并管理其中的打印作业（更多信息，请参阅 go.microsoft.com/fwlink/?LinkId=111534）。请注意，在 Windows Server 2008 中此功能被禁用。

当人们以 User 身份运行 Windows XP 时，经常取笑它的时钟功能（或者没有此功能）——尝试以 User 身份双击时钟（人们经常用这种方式来查看日期，无论它的设计本意是否如此）——您会看到图 6 所示的错误。这不是很友好。在 Windows XP 中，通过修改策略可使用户能够执行此操作，但在 Windows Vista 中，已经改为以这种方式运行。总而言之，以 User 身份运行时，无论是使用 UAC 还是以正式 User 身份运行并提升为另一用户，在 Windows Vista 中通常都要比在 Windows XP 中更人性化。

Figure 6** In Windows XP, non-admins couldn't change the time **(单击该图像获得较大视图)

记住限制

请记住，将用户转换成非管理用户并非是万能灵药。对于那些实际上掌管着自己的计算机的最终用户而言，他们可以千方百计地寻找其系统的漏洞，尤其是当策略或 User 权限使其感到不便或令其无法完成工作时。

如果用户以 Administrator 身份运行，则无需费力就可以绕过已有的任何组策略。当然，再多费一点事，用户可以引导到 Windows PE 并修改一些通常情况下他并不具有的权限（尽管在使用 BitLocker 或其他驱动器/卷加密时，可以使其无法实现此操作，或者至少会困难一些）。

如果您的组织尚未开始将最终用户转换成以 User 身份运行，您现在需要做的最重要的事情就是了解您和您的组织为什么要花费时间、金钱和精力来改变用户以 Administrator 身份运行的现状。

的确，有一些旧应用程序可能无法再使用，但是如果为了迁就某个无法以 User 身份运行的应用程序而损害组织的安全则有些得不偿失。可以考虑虚拟化该应用程序——将其移到用户能真正作为管理员运行的虚拟机中。这不但使您可以在需要时继续使用该应用程序，而且还可以通过将 Administrator 身份转换成 User 身份来保护系统剩余部分的安全。

请注意，在整个专栏中，我没有使用“锁定”或类似的衍生词。许多人都把将 Administrator 转换成 User 看作是常常使用该词描述的任务的一部分。也许是由于我的心理学背景的原因或与我目前所处的市场营销领域有关，我认为千万不要使用会使最终用户感觉其权限被剥夺的词汇（即使只是语义上的）。

相反，应该关注组织的安全利益，并确保针对一些边缘情况（特定用户根本无法以 User 身份运行的任务或需要管理权限才能执行的特定任务）制定出合理的计划。无论是使用某些手动方法（如 Run.vbs 脚本，可在 technetmagazine.com/issues/2007/03/DesktopFiles 上找到）还是通过商业解决方案来帮助您实现转换（它可以向最终用户隐藏转换细节，使工作一步到位），都必须尽快开始执行到非管理员身份的转换。**《TechNet 杂志》的撰稿人 Aaron Margosis 是以非管理员身份运行的倡导者。如果您还不熟悉他的博客，则应该仔细研究一下——它是深入了解此主题的最佳去处（请参阅 blogs.msdn.com/aaron_margosis）。

Wes Miller 目前是位于德克萨斯州奥斯汀市的 CoreTrace 公司 (www.CoreTrace.com) 的高级技术产品经理。在此之前，他在 Winternals Software 公司任职，并曾在 Microsoft 担任项目经理。您可以通过电子邮件 technet@getwired.com 与 Wes 联系。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.