深入理解Windows Vista UAC—以标准用户身份运行[谢绝转载]
在Windows Vista中，用户帐户控制（UAC）这个特性经常会受到误解。在Mark的 “Windows Vista内核改进” 三篇系列文章中（technetmagazine.com在线阅读），并没有提到有关UAC的内容，这是因为Mark觉得应该为UAC单独写一篇文章。
在这篇文章里，Mark讨论了UAC所解决的问题，并对其组件架构和实现机制进行描述。这些机制包括把原本需要管理特权的操作分离出来、让程序可以在标准特权环境下正常运行的简单虚拟化功能，让程序明确请求管理特权，以及在同一个用户桌面上把管理员进程和非管理员进程隔离开来。
UAC的目标
UAC的目的是让用户运行在标准用户特权下，而不是管理员特权。管理员特权可以让用户读取和修改操作系统的任意地方，包括其他用户的代码和数据—甚至Windows自己。没有管理员特权，用户就不能有意或者无意地修改系统设置，恶意软件就无法修改系统的安全设置或禁用杀毒软件，共享计算机上的用户也不能获取其他用户的机密数据。以标准用户特权运行，可以在企业环境里有效地减少紧急技术支持电话开销，减少恶意软件的影响，让家用计算机更加平稳地运行，并对共享计算机上的机密数据进行保护。
UAC必须对一些问题进行解决，以便可以在标准用户帐户上实际运用。首先，在Windows Vista之前，Windows使用模型假设用户具有管理员特权。软件开发商假设程序可以访问和修改任何文件、注册表键值或者系统设置。甚至当Windows NT引入安全的概念，并且区分管理员和标准用户的访问权限，安装程序还是会指导用户使用内置Administrator帐户、或者管理员组的成员帐户。
UAC所必须解决的第二个问题是：有时候用户必需管理员特权，才能执行诸如安装软件、更改系统时间和打开防火墙端口之类的操作。
为了解决这些问题，UAC的解决方案是让绝大多数应用程序运行在标准用户特权下，排除管理员特权的需要，并且鼓励软件开发商开发可以在标准用户特权下运行的应用程序。UAC通过以下方法实现目的：减少用到管理员特权的频率、让旧版应用程序可以运行在标准用户特权下、标准用户在需要时可以方便地获得管理员特权、就连管理员用户也可以运行在标准用户特权下。
以标准用户身份运行
Windows Vista的开发阶段对所有的管理员操作进行完全审核，结果发现许多操作可以在标准用户下完成，这样就不会破坏系统安全。举个例子，哪怕企业已经为其Windows XP桌面系统部署标准用户帐户，但是他们还是无法把移动用户从管理员组中删除，这仅仅是因为Windows XP无法把更改系统时区和更改系统时间区分开来。笔记本用户需要能够配置系统时区，这样他们在旅行时才可以在日历中看到正确的日程安排，而这需要拥有“更改系统时间”特权（Windows内部叫做SeSystemTimePrivilege），而只有管理员组成员才拥有这个特权。
像Kerberos这样的安全协议需要用到时间的概念，但是时区则只影响时间的显示方法，所以Windows Vista添加了一个新的特权，“更改系统时区”（SeTimeZonePrivilege），如附图所示。这样，许多企业就有可能让其笔记本用户工作标准用户环境下。
盆盆译注：盆盆在《Windows Vista安全原理深入探索》一文里，曾经提到“SeTimeZonePrivilege”特权的概念。
Windows Vista也允许标准用户配置WEP设置以连接无线网络、创建VPN连接、修改电源管理设置、以及安装关键Windows更新。此外，通过组策略设置，标准用户可以安装经过IT管理员批准的打印机或者其他设备驱动程序、安装经过管理员批准站点上的ActiveX控件。
那么个人或者关键业务程序又该如何呢，这些程序可能无法正常运行在标准用户下。尽管有些应用程序确实需要管理员特权，但是许多程序把用户数据不必要地保存在系统全局位置。安装程序通常运行在管理员特权下，微软推荐它们在%ProgramFiles%下创建子目录，以存放可执行文件和其他文件，并在HKEY_LOCAL_MACHINE\Software下新建注册表项，以存放应用程序设置。当应用程序启动时，可以运行在其他用户帐户下，因此应该把特定用户的数据存放在%AppData%目录（每用户位置）下，而把特定用户配置信息存放在HKEY_CURRENT_USER\ Software（用户的注册表配置单元）。标准用户没有权限写入%ProgramFiles%目录或者HKEY_LOCAL_MACHINE\Software注册表项，但由于Windows Vista之前，绝大多数Windows系统都是单用户，而绝大多数用户都是管理员组成员，所以尽管应用程序把用户数据和设置错误地保存在这些位置，但是它们可以照常运行。
盆盆译注：以前很多应用程序在Windows XP的标准用户下不能正常运行，例如腾讯QQ，就无法正常运行，这是因为它把用户数据错误地保存在Program Files目录下。
Windows Vista采用了文件系统和注册表虚拟化技术，以帮助旧版应用程序在标准用户下正常运行。当应用程序试图修改文件系统或注册表中的系统全局区域，会由于访问拒绝而操作失败，而Windows则会把这些操作重定向到每用户位置（per-user）；当应用程序试图读取系统全局区域的信息，Windows就会首先在每用户位置进行检查，如果没有发现所需的信息，再到全局位置尝试读取。
只有旧版应用程序才能进行虚拟化，而要被Windows Vista看成是旧版应用程序，必须是32位代码（而非64位）、不以管理员身份运行、并且没有程序清单（因而不会认为是专为Windows Vista所编写）。只要不是由旧版应用程序所发起的操作，就不会实施虚拟化，包括网络文件共享访问等。进程的虚拟化状态会作为一个标记保存在访问令牌里，访问令牌是内核数据结构，用来追踪进程的安全上下文，包括其运行帐户、组成员关系和特权。
在任务管理器的“进程”标签页里添加一列“虚拟化”选项，就可以查看进程的虚拟化状态。附图显示绝大多数Windows Vista组件，包括Desktop Window Manager (Dwm .exe)、Client Server Runtime Subsystem (Csrss.exe)和 Explorer，都禁用虚拟化，因为这些进程要么具有Windows Vista程序清单，要么运行在管理员状态下，所以禁用虚拟化。而Internet Explorer(iexplore.exe)则启用虚拟化，因为IE进程包含多个ActiveX空间和脚本，所以必须假设它们在标准用户下无法正常工作（因而需要借助虚拟化）。
盆盆译注：也许Mark Russinovich犯了小小的失误，其实IE进程的虚拟化和UAC的虚拟化，并不是一回事。IE保护模式的虚拟化是一套独立的机制。大家不妨想一下，IE保护模式的虚拟化，为什么要和UAC独立？
旧版应用程序的文件系统虚拟化位置包括%ProgramFiles%、%ProgramData%和%SystemRoot%，除了其中的部分子目录外。然而，任何可执行文件扩展名，例如.exe、.bat、.scr和.vbs等，都会排除在外。这意味着程序在标准用户下进行自我升级会遇到失败，而并不会创建一个私有版本的可执行文件（运行全局升级程序的管理员看不到）。要把其他扩展名添加到例外列表中，只需把它们添加到以下的注册表项并重启：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
新建多字符串类型的键值，可以输入多个扩展名，但是注意扩展名前不要加前缀“.”。
旧版应用程序对系统全局目录所做的修改，会重定向到用户的虚拟根目录%LocalAppData%\VirtualStore。例如，假设笔者系统上的旧版进程要创建C:\Windows\Application.ini，实际上创建的文件是C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini。虚拟路径中包含“Local”（盆盆译注：是指%LocalAppData%），这说明如果帐户有漫游配置文件，虚拟文件不会重定向到漫游配置文件中。
如果打开“计算机”窗口查看包含虚拟文件的目录，则会显示一个名为“兼容性文件”的按钮，如附图所示。单击该按钮，即可进入相应的VirtualStore目录，在其下可以看到虚拟文件。
UAC文件虚拟筛选驱动程序(%SystemRoot%\System32\Drivers\Luafv.sys)实现文件系统虚拟，如附图所示。因为是文件系统筛选驱动程序，所以它可以看到所有的文件系统操作，但是只对旧版应用程序实施虚拟化。我们可以看到当旧版进程试图在系统全局位置创建文件时，Luafv.sys会替它改变目标文件的路径，但是并不会替标准用户下的Windows Vista应用程序做同样的操作。旧版应用程序相信文件操作已经成功了，但是实际上是在用户有权访问的位置创建文件，但是\Windows目录的默认权限会拒绝Windows Vista应用程序的访问。
盆盆译注：从图中可以看出，旧版应用程序从用户模式发出创建文件请求，内核模式下的Luafv.sys会把这种请求重定向到本地的User Profile，然后再把这种请求转发给NTFS文件系统驱动程序（NTFS.sys）。而Windows Vista应用程序的请求则会直接拒绝访问。
注册表虚拟化的实现和文件系统虚拟化有些不同。需要虚拟化的注册表项大多位于HKEY_LOCAL_MACHINE\SOFTWARE分支，但是其下有很多例外，包括：
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
只有旧版应用程序经常修改的注册表项，但是又不会导致兼容性和互操作性问题的，才会进行虚拟化。当旧版应用程序需要修改注册表时，Windows会把需要虚拟化的注册表项重定向到HKEY_ CURRENT_USER\Software\Classes\VirtualStore。该注册表项位于用户的类配置单元文件，%LocalAppData%\Microsoft\Windows\UsrClass.dat，和其他虚拟化文件数据一样，不能在漫游配置文件中进行漫游。
和文件系统虚拟不一样，Windows并没有维护一个注册表虚拟化的固定位置列表，而是把注册表项的虚拟化状态作为一个标记保存，REG_ KEY_DONT_VIRTUALIZE。Reg.exe实用程序可以显示该标记、以及其他两个虚拟化相关标记，REG_KEY_DONT_SILENT_FAIL和REG_KEY_ RECURSE_FLAG，如附图所示。
如果注册表项设置了REG_KEY_DONT_SILENT_FAIL标记，同时又设置了REG_ KEY_DONT_VIRTUALIZE标记（不能虚拟化），假设旧版应用程序要对某个注册表项进行操作，原本会拒绝访问，这时候会获得用户对该注册表项所具有的任何访问权限，而不是应用程序所请求的权限。REG_KEY_ RECURSE_FLAG标记则显示新的子项是否继承父项的虚拟化标记（而不仅仅是默认的标记）。
注册表虚拟化是由配置管理器所实现的，这是操作系统内核（Ntoskrnl.exe）管理注册表的组件。和文件系统虚拟化一样，如果旧版应用程序要在系统全局的注册表项下新建子项，会被重定向到用户的注册表虚拟根键下，但是Windows Vista应用程序则会直接拒绝访问。
除了文件系统和注册表虚拟化，一些应用程序还需要其他的帮助才能在标准用户下正常运行。举个例子，如果应用程序的测试帐户属于管理员组，则可以正常工作，如果不属于管理员组，则无法正常工作。因此Windows Vista提供了一系列应用程序兼容性修补数据库，以便这些应用程序可以正常运行。最常用的修补数据库如附图所示，可以帮助旧版应用程序在标准用户特权下正常工作。企业IT部门可以借助ACT（technet.microsoft .com/windowsvista/aa905066.aspx）和Standard User Analyzer (SUA)，或者Aaron Margosis所编写的LUA Buglight，来判断应该为他们的关键业务程序应用哪些修补数据库。他们可以借助Compatibility Administrator（也是ACT中的组件）给应用程序指派修补数据库，然后借助组策略把结果产生的兼容性数据库（.sdb文件）部署到桌面计算机上。注意，如果需要，可以使用本地安全策略彻底禁用虚拟化功能。
虚拟化的影响
我们可以在任务管理器的“进程”标签页里，用鼠标右键单击某个进程，在弹出菜单上选择“虚拟化”命令，即可改变进程的虚拟化状态。附图显示当虚拟化状态改变时，命令提示符的行为变化。刚开始启动时，虚拟化功能是禁用的，因为它具有Windows Vista程序清单。因为它运行在标准用户特权下，所以无法在C:\Windows目录下新建文件，但是如果用任务管理器启用虚拟化，这时候从表面上看可以成功新建文件。这时候再禁用虚拟化，它就无法找到刚才新建的文件，该文件实际上是在用户的配置文件夹里。
翻译自：
Mark Russinovich
http://www.microsoft.com/technet/technetmag/issues/2007/06/UAC/default.aspx?loc=en-us