转深入了解Windows7的用户账户控制UACWord格式.docx

转深入了解Windows7的用户账户控制UACWord格式.docx

《转深入了解Windows7的用户账户控制UACWord格式.docx》由会员分享，可在线阅读，更多相关《转深入了解Windows7的用户账户控制UACWord格式.docx（9页珍藏版）》请在冰豆网上搜索。

演示示例展示了WindowsXP和WindowsVista上有关设置时区的权限要求的不同之处。

在WindowsXP上，更改时区需要管理权限，实际上，即使是使用时间/日期控制面板小程序查看时区也需要管理权限。

　　这是因为WindowsXP未将更改时间（安全敏感的系统操作）与更改时区（只是影响时间的显示方式）区分开来。

在WindowsVista（和Windows7）中，更改时区不是一项管理操作，并且时间/日期控制面板小程序也将管理操作与标准用户操作进行了分隔。

仅仅这一项更改就让许多企业能够为出差的用户配置标准用户帐户，因为用户将能够调整时区来反映他们的当前位置。

Windows7进一步做出了改进，比如刷新系统的IP地址、使用WindowsUpdate来安装可选的更新和驱动程序、更改显示DPI，以及查看标准用户可访问的当前防火墙设置。

　　文件系统和注册表虚拟化在后台工作，可以帮助许多无意间使用管理权限的应用程序在没有管理权限的情况下也能正常运行。

对于不必要地使用管理权限而言，最常见的情况是将应用程序设置或用户数据存储在注册表或文件系统中系统所使用的区域内。

举例来说，某些旧版应用程序将其设置存储在注册表的系统范围部分（HKEY_LOCAL_MACHINE\Software），而不是每用户部分（HKEY_CURRENT_USER\Software），而注册表虚拟化会将尝试写入系统位置的操作转到HKEY_CURRENT_USER（HKCU）中的位置，同时保持应用程序兼容性。

　　设计PA帐户的目的是为了鼓励开发人员将应用程序编写为只需要标准用户权限，同时使尽可能多的在管理组件和标准用户组件之间共享状态的应用程序能够继续工作。

默认情况下，WindowsVista或Windows7系统上的第一个帐户（在Windows的早期版本上为完全权限管理员帐户）是PA帐户。

PA用户执行的任何程序都使用标准用户权限运行，除非用户明确提升了应用程序，即授予应用程序管理权限。

诸如安装应用程序和更改系统设置等用户活动会触发提升权限提示。

这些提升权限提示是最显著的UAC技术，表现形式为切换到一个包含允许/取消对话框的屏幕，背景为灰色的桌面快照。

　　在安装之后创建的帐户是标准用户帐户，默认情况下，这些帐户通过一个“即时权限提升”提示提供提升功能，该提示要求提供将用于授予管理权限的管理帐户的凭据。

利用这一便捷功能，只要共享家庭计算机的家庭成员或更注重安全的使用标准用户帐户的用户知道管理帐户的密码，他们就能够用管理权限来运行应用程序，而不必手动切换到其他用户登录会话。

此类应用程序的常见示例包括安装程序以及家长控制配置。

　　在启用了UAC后，所有用户帐户（包括管理帐户）都将使用标准用户权限运行。

这意味着，应用程序开发人员必须考虑他们的软件默认情况下将没有管理权限这一事实。

这应会提醒他们将其应用程序设计为使用标准用户权限工作。

如果应用程序或其功能的某些部分需要管理权限，它可以利用提升机制来允许用户解锁该功能。

通常，应用程序开发人员只需进行少许更改就可让其应用程序使用标准用户权限正常工作。

如有关UAC的E7博客文章所述，UAC成功地改变了开发人员编写软件的方式。

　　提升权限提示的另一个优点是：

它们能够在软件想要对系统进行更改时“通知”用户，并使用户有机会来阻止这种情况。

例如，如果用户不信任或不想允许修改系统的软件包要求管理权限，则它们可以拒绝提示。

　　提升和恶意软件安全性

　　UAC的主要目标是让更多用户能够使用标准用户权限运行。

但是，其中一项UAC技术看起来像是安全功能：

许可提示。

许多人认为，因为软件必须要求用户授予其管理权限，因此他们能够防止恶意软件获得管理权限。

提示是一种视觉暗示，它仅为其所述操作获取管理权限，除此之外，用户还可以切换到不同桌面来显示提升对话框，以及使用Windows完整性机制，包括用户界面特权隔离（UIPI），这些都使人们更加坚信这一理念。

　　正如在WindowsVista推出之前我们所谈到的，提升的主要目的不是安全性，而是其方便性：

如果用户必须通过登录到管理帐户或通过“快速用户切换”切换到管理帐户，从而切换帐户以执行管理操作，则大多数用户都只会切换一次，而不会切换回来。

更改应用程序开发人员进行设计所针对的环境将不会有进展。

那么，安全桌面和Windows完整性机制的目的是什么?

　　为提示切换到不同桌面的主要原因是：

标准用户软件无法“欺骗”提升权限提示，例如，它们无法通过在对话框上的发布者名称上绘图来欺骗用户，让用户认为是Microsoft或另一个软件供应商（而不是这些软件）生成了提示，从而欺骗提升权限提示。

这种替代桌面称为“安全桌面”，因为它是系统（而不是用户）所拥有的，就像系统显示Windows登录对话框的桌面一样。

　　使用其他桌面还有一个重要目的，就是为了实现应用程序兼容性：

在正在运行其他用户拥有的应用程序的桌面上，如果内置辅助功能软件（比如屏幕键盘）能够正常工作，那么此时就有一个第三方软件不能正常工作。

当本地系统帐户拥有的提升对话框显示在用户拥有的桌面上时，该软件将无法正常工作。

　　Windows完整性机制和UIPI的设计目的是在提升的应用程序周围建立一道保护性屏障。

它最初的目标其中之一是防止软件开发人员投机取巧，利用已经提升的应用程序来完成管理任务。

使用标准用户权限运行的应用程序无法将合成鼠标或键盘输入发送到提升的应用程序中，以使应用程序执行其指令，也无法将代码注入提升的应用程序以执行管理操作。

　　Windows完整性机制和UIPI在WindowsVista中用于保护模式InternetExplorer，使得感染IE的运行实例的恶意软件更难于修改用户帐户设置，例如，将本身配置为在每次用户登录时启动。

尽管WindowsVista的一个早期设计目标是使用带有安全桌面的提升、Windows完整性机制和UIPI，在使用标准用户权限和管理权限运行的软件之间建立一个坚不可摧的屏障（称为安全边界），但由于以下两个原因，而导致该目标未能实现，并随之被放弃：

可用性和应用程序兼容性。

图1显示可执行文件的名称。

　　首先，考虑提升对话框本身。

它显示将被授予管理权限的主要可执行文件的名称和发布者。

遗憾的是，尽管越来越多的软件发布者为其代码添加了数字签名，但仍然有一些软件发布者没有这样做，并且还有许多未添加签名的旧版应用程序。

对于未签名的软件而言，提升对话框只会显示可执行文件的文件名，因此，对于某些恶意软件（例如，已采用用户帐户运行并且正在监视未签名Setup.exe应用程序安装程序的提升）而言，将能够将可执行文件替换为恶意的Setup.exe，而用户却一无所知（请参阅图1）。

　　其次，该对话框不会告知用户可执行文件在启动时将会加载哪些DLL。

如果可执行文件位于用户可以控制的目录中，则使用用户标准权限运行的恶意软件将能够替换该位置中软件将使用的任何关联DLL。

此外，恶意软件可以使用并行功能，使可执行文件加载应用程序或系统DLL的恶意版本。

并且，除非用户警惕地单击详细信息按钮，并仔细查看为提升可执行文件列出的文件路径，否则恶意软件可以将可执行文件复制到名称类似的位置，例如，\ProgramFiles\Vendor\Application.exe（注意应为“ProgramFiles”的内容中缺少的空格），在该位置中，恶意软件将可控制应用程序加载哪些DLL。

在图2中，我已将Microsoft网络监视器的一个组件复制到用户创建的C:

\ProgramFiles目录（用户可控制该目录），并启动了该组件。

图2已启动的Microsoft网络监视器组件的副本。

　　最后，为了实现应用程序兼容性，提升的应用程序与标准用户环境共享实质性状态，恶意应用程序可以使用该状态来影响提升的应用程序的行为。

就这一点而言，最直观的示例就是用户的注册表配置文件HKEY_CURRENT_USER（HKCU）。

该配置文件是共享的，因为用户希望他们作为标准用户注册的设置和扩展能够在提升的应用程序中工作。

恶意软件可以使用HKCU中注册的外壳扩展来加载到使用任何外壳浏览对话框（比如“打开文件”和“保存文件”）的已提升应用程序中。

其他各种状态也是共享的，特别是基本命名对象命名空间，应用程序将在其中创建同步和共享内存对象。

举例来说，恶意软件可以利用该共享来劫持提升的应用程序使用的共享内存对象，从而对应用程序和系统造成危害。

　　至于Windows完整性机制，由于我前面提到的提升问题，因此它作为屏障的有效性是有限的，而它还存在由于应用程序兼容性而导致的限制。

举例来说，UIPI不会阻止标准用户应用程序在桌面上绘图，这一点可能会被用来欺骗用户，采用为恶意软件授予管理权限的方式来与提升的应用程序交互。

同时，Windows完整性机制也不能跨网络应用。

采用PA帐户运行的标准用户应用程序将能访问PA帐户具有管理权限的远程系统上的系统资源。

如果解决这些限制，将会对应用程序兼容性造成很大影响。

尽管如此，我们一直在探寻提高系统安全性（例如，改善保护模式IE），同时解决应用程序兼容性问题并与软件开发人员密切配合的方法。

　　那么，当您在启用了UAC的情况下采用WindowsVistaPA帐户运行时，您将得到什么程度的恶意软件防护?

首先，请记住，要使任何这种情况发生，恶意软件首先必须进入系统并且开始执行。

Windows具有许多深层防御功能，其中包括数据执行保护（DEP）、地址空间加载随机化（ASLR）、保护模式IE、IE8浏览器 

SmartScreen筛选器，以及可以帮助防止恶意软件进入系统并运行的WindowsDefender。

　　至于恶意软件通过某种方式成功进入系统的情况，由于恶意软件作者（比如合法的开发人员）假设用户使用管理权限运行，因此大多数恶意软件将无法正常工作。

仅这一点可以被视为一种安全优势。

但是，已进入系统并且设计为可利用这些机会的恶意软件将能够在用户第一次提升时获得管理权限—但恶意软件甚至不需要等待“实际”提升，因为它可以促成提升，而这种提升甚至可以欺骗最注重安全的用户。

我已经在我的UAC内部信息和Windows安全边界演示文稿中公开演示过恶意软件如何能够劫持提升过程（演示位于安全边界讨论的1分03秒处）。

但是，请记住，如果恶意软件已经开始运行，它只需使用标准用户权限就可达到恶意软件想要达到的大部分目的，其中包括将本身配置为在每次用户登录时运行、窃取或删除所有用户的数据，或者甚至成为僵尸网络的一部分。

　　Windows7中的不同之处

　　我在前面提过，Windows7中的某些操作现在可由标准用户执行，但正如有关UAC的E7博客文章所述，我们还认识到，我们可以在不影响UAC的目标的情况下使Windows体验更加流畅。

许多用户抱怨说，当他们执行常见的系统管理操作时，WindowsVista本身会频繁地请求管理权限。

使Windows能够针对标准用户环境正常工作对我们最有利，因为这样将为我们的客户带来利益。

但是，提升权限提示并没有告诫或鼓励我们这样做，而是会强制用户在绝大多数用户都不理解的对话框中再次单击。

因此，Windows7开始从默认Windows体验中最大程度地减少这些提示，并使以管理员身份运行的用户能够控制其提示体验。

　　为此，我们进一步重构了系统，这样，拥有标准用户权限的用户将能执行更多任务，并且，我们减少了若干多提示方案（例如，在IE中安装ActiveX控件）中的提示数量。

Windows7还引入了两种新的UAC操作模式，可以在新的UAC配置对话框（请参阅图3）中选择这些模式。

通过转到控制面板，单击“用户帐户”，单击“用户帐户”，然后单击“更改用户帐户控制设置”，您可以打开该对话框。

（您也可以通过单击提升权限提示上的“显示这些通知时进行更改”链接或通过访问“操作中心”来进入该对话框。

）

图3可在新的UAC配置对话框中选择的两种新UAC操作模式。

　　图3中显示的默认设置就是其中一个新级别。

与位于滑块顶部并相当于WindowsVista中的默认模式的“始终通知”不同，只有当非Windows可执行文件请求提升时，Windows7才会默认提示用户;

针对非Windows提升的行为与WindowsVista相同。

　　下面接下来的滑块位置是第二个新设置，它的标签相同，只是后面附加了“（不降低桌面亮度）”。

该模式和默认模式的唯一不同之处在于：

提示将出现在用户的桌面（而不是安全桌面）上。

这样的好处是：

用户可以在提示处于活动状态的同时与桌面交互，但正如我之前提到的，将会出现第三方辅助功能软件可能无法在该提示对话框上正常工作的风险。

　　最后，如果选择最底部的滑块位置，将会完全禁用UAC技术，这样，所有采用PA帐户运行的软件都将使用完全管理权限运行、文件系统和注册表虚拟化将被禁用，并且保护模式IE将被禁用。

尽管采用此设置时将没有提示，但保护模式IE的损失是此模式的一个很大的弊端。

　　自动提升

　　在采用中间两种设置时，之所以（大多数）Windows可执行文件的提升不会产生提示，其原因在于系统“自动提升”了Windows可执行文件。

首先，在此上下文中，Windows对Windows可执行文件的定义是什么?

答案取决于若干因素，但有两个条件必须得到满足：

该可执行文件必须经过WindowsPublisher的数字签名，WindowsPublisher是用于对Windows附带的所有代码进行签名的证书（仅由Microsoft进行签名是不够的，因此Windows未附带的Microsoft软件不包括在内）;

并且该可执行文件必须位于其中一个为数不多的“安全”目录中。

安全目录是指标准用户无法修改的目录，并且它们包括%SystemRoot%\System32（例如，\Windows\System32）及其大多数子目录、%SystemRoot%\Ehome，以及%ProgramFiles%下的少许目录（其中包括WindowsDefender和Windows日记本）。

　　同时，视可执行文件是普通.exe、Mmc.exe还是COM对象而定，自动提升还有一些附加规则。

如果.exe种类的Windows可执行文件（如前面所定义）在其清单中指定了autoElevate属性，这些可执行文件将会自动提升。

应用程序也将在该清单中向UAC指明它们需要管理权限。

此处的SysinternalsSigcheck实用工具通过命令“sigcheck–m%systemroot%\system32\taskmgr.exe”来转储任务管理器（Taskmgr.exe）的清单，该清单显示任务管理器已加入自动提升，如图4所示。

图4autoElevate属性

　　在目录树中查找自动提升可执行文件的一种简便方法是，通过如下所示的命令使用SysinternalsStrings实用工具：

　　strings–s*.exe|findstr/iautoelevate

　　还有一个硬编码列表，其中包含获得自动提升处理的Windows可执行文件。

这些Windows可执行文件也并非是Windows7附带的内部文件，因此它们必须能够在autoexecute属性会导致错误的旧版系统上运行。

列表中包括Migwiz.exe（迁移向导）、Pkgmgr.exe（程序包管理器）和Spinstall.exe（ServicePack安装程序）。

　　将对Microsoft管理控制台Mmc.exe进行特殊处理，因为它承载了多个以DLL形式实现的系统管理管理单元。

Mmc.exe通过命令行启动，该命令行指定一个.MSC文件，其中列出要加载的管理单元MMC。

Mmc.exe将在通过PA帐户启动时请求管理权限，当Windows发现这一点时，它将验证Mmc.exe是否为Windows可执行文件，然后检查.MSC。

为了获得自动提升资格，.MSC文件必须满足Windows可执行文件条件（由Windows在安全的位置中签名），并且必须列在自动提升.MSC的内部列表中。

该列表实际上包括Windows附带的所有.MSC文件。

　　最后，COM对象可以通过创建一个名为Elevation的子项（其名为Enabled的值设置为1），利用其注册表项中的注册表值来指定需要管理权限。

图5显示了外壳的“复制”/“移动”/“重命名”/“删除”/“链接”对象的注册表项，当用户对其帐户没有权限访问的位置执行文件系统操作时，资源管理器将使用该对象。

图5外壳注册表项

　　要使COM对象能够自动提升，它还必须是Windows可执行文件，并且必须已由Windows可执行文件进行实例化。

（不过，无需将实例化可执行文件标记为自动提升。

）例如，当您使用资源管理器通过PA帐户在%ProgramFiles%目录中创建目录时，操作将会自动提升，因为COM对象请求了提升、对象的DLL是Windows可执行文件，并且资源管理器是Windows可执行文件。

　　自动提升与UAC的目标

　　那么，所有特殊自动提升规则背后的原理是什么?

选择要自动提升哪些程序以及不自动提升哪些程序是由以下问题确定的：

“应用程序开发人员是否能够利用自动提升无意间或不费力地依赖于管理权限?

”由于可以使用Cmd.exe通过命令行参数来执行批处理脚本，并且普通用户不需要以提升方式运行命令提示符（大多数用户甚至不知道命令提示符是什么），因此未将Cmd.exe列入自动提升的清单。

同样，承载控制面板插件的可执行文件Rundll32.exe在Windows7的最终版本中也未自动提升，因为对于任何常见管理任务而言，并不需要对其进行提升，并且，如果Rundll32.exe进行了自动提升，则它通过命令行承载任意DLL的能力将会导致开发人员要求使用管理员权限，而自己却未意识到。

　　自WindowsVista测试版发布以来，最终用户一直在要求Windows提供一种向自动提升列表中添加任意应用程序的方法。

经常被提及的原因是：

他们常用的某个第三方应用程序强制他们不断单击提升权限提示，而这已经成为他们日常工作的一部分。

就像WindowsVista一样，Windows7并未提供这种功能。

我们理解这种操作非常繁琐，并且可能有这些应用程序无法在没有管理权限的情况下运行的合理原因，但开发人员将会避免将其代码修正为使用标准用户权限，而这样的风险太高。

即使有关哪些应用程序进行自动提升的列表只能由管理员访问，但开发人员只需更改其要求一次性提升的应用程序安装程序，就可将其应用程序添加到列表中。

作为替代，我们选择进行投资来进行培训并与应用程序开发人员密切合作，以确保其程序能够以标准用户身份正常工作。

　　很多人发现，采用PA帐户通过标准用户权限运行的第三方软件可以利用自动提升来获取管理权限。

例如，软件可以使用WriteProcessMemoryAPI将代码注入资源管理器，并使用CreateRemoteThreadAPI来执行该代码，这种技术称为DLL注入。

由于代码在资源管理器（一种Windows可执行文件）中执行，因此它可以利用自动提升的COM对象（比如“复制”/“移动”/“重命名”/“删除”/“链接”对象）来修改系统注册表项或目录，并为软件授予管理权限。

如果是这样，这些步骤将需要蓄意谋划，而且并非无关紧要，因此，与将其软件修正为使用标准用户权限来运行相比较，我们不相信正当的开发人员会选择进行这些步骤。

事实上，我们建议任何应用程序开发人员不要依赖于系统中的提升行为，并且建议应用程序开发人员测试其软件在标准用户模式下运行的情况。

　　接下来的发现是，恶意软件可以使用同样的技术获取管理权限。

同样，情况确实如此，但正如我前面指出的，恶意软件也可以通过提示的提升来危害系统。

从恶意软件的角度来看，Windows7的默认模式并不比“始终通知”模式（“Vista模式”）安全多少，并且，采用管理权限的恶意软件在Windows7的默认模式下运行时，将仍然会崩溃。

　　结论

　　总而言之，UAC是一组具有一个整体目标的技术：

使用户能够以标准用户身份运行。

因为对Windows进行了更改，使标准用户能够执行以前需要管理权限的更多操作，再结合文件和注册表虚拟化以及提示，从而共同实现了此目标。

最终标准是：

默认的Windows7UAC模式通过减少提示使PA用户的体验更加流畅、允许用户控制可以修改其系统的合法软件，并仍然实现UAC的目标，即让更多的软件能够在没有管理权限的情况下运行，并继续使软件生态系统转变为编写能够使用标准用户权限工作的软件。