Windows Vista的UAC功能浅析(1)
原文摘自ITECN博客，作者：盆盆< Microsoft MVP ITECN博客站长>
ITECN博客，是由盆盆等MVP组织发起的、旨在研究和推广微软IT Pro技术的网站，由多位Microsoft MVP和资深微软认证讲师组成。ITECN博客的网址是http://blogs.itecn.net
本文由“ITECN”版权所有，仅授权PChome电脑之家发表，任何媒体没有“ITECN”同意不得擅自转载，转载必追究，后果自负。
看过《关闭计算机中恼人的beep噪音》(http://blogs.itecn.net/blogs/ahpeng/archive/2006/02/28/1856.aspx)一文的朋友，在对Windows Vista进行操作的时候需要格外注意！
由于Windows Vista默认启用UAC功能，CMD Shell以Standard User的身份启动，我们无法采用sc命令对beep服务进行配置(会收到Access is Denied的错误消息)。
这时候必须右键单击开始菜单上的“Command Prompt”，选择“Run as administrator”，以Highest Privilege运行CMD Shell，这样SC命令才能拿到足够特权完成相应的管理工作。如下图所示，淡青底色的CMD Shell以Standard User身份运行(结果SC命令运行失败)，而红底色的CMD Shell则以Highest Privilege运行(结果SC命令运行成功)。
图1
提示 有关Windows Vista中CMD Shell的UAC功能“失灵”的另一个实例，可以参考MVP Smallfrog的帖子：
http://blogs.itecn.net/blogs/smallfrogs/archive/2006/02/26/1832.aspx
Windows Vista的UAC功能浅析(2)
UAC的两大要素
那么，为什么说在当前CTP Build的Windows Vista中，CMD Shell的UAC功能是“失灵”的？
窃以为，真正意义上的UAC，必须至少同时满足以下两个条件：
? 用户进程运行standard user安全环境下，这点CMD Shell可以做到。
? 当系统"识别"出目标进程需要高级特权才能完成，就会自动弹出提升特权确认对话框(consent进程)，得到确认后，会以最高特权运行目标进程。
只有自动识别、自动提升特权，才能算是UAC的精髓！
否则在Windows XP一样可以让用户进程运行在Standard User环境(可以参考笔者的《IE浏览器，我想你安全、再安全些》)，但是这充其量只能算是LUA(最小帐户特权)，而不够格称为UAC(用户帐户控制)！
修改UAC兼容性设置
能不能修改SC命令的兼容性设置，让系统知道它需要管理员权限？
但是打开SC命令的属性对话框，发现其兼容性设置被锁死，如下图所示，原因是SC命令属于系统内置的组件，这和Windows XP的情况一样。
图2
Windows Vista的UAC功能浅析(3)
这里尝试修改注册表，试图绕过这个限制，把SC命令添加到系统的兼容性数据库中：
(1) 打开regedit注册表编辑器，定位到以下注册表项：
HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers
(2) 新增一个字符串键值：
名称必须设置为“C:Windowssystem32sc.exe”
并将其数值数据设置为“RUNASADMIN”
提示 该注册表修改完全等效于如图2所示的兼容性设置，只是绕开了UI的限制。
现在打开一个Standard User的CMD Shell，再尝试运行SC命令，系统也会弹出consent确认对话框，如下图所示。
图3
确认后系统会自动打开一个新的CMD窗口运行SC命令，只是该窗口会一闪而过，让人来不及反应，但是SC命令确实是在高特权下运行的。
显然上述的注册表修改法并不是解决问题的良药，实际上这只是强行把“皮球”踢给Explorer Shell(GUI)罢了，执行的结果也并不理想，更何况数百个命令行工具，逐个修改的话，简直是一场噩梦！
Windows Vista的UAC功能浅析(4)
Windows Vista区别对待不同的进程
同样是系统内置的组件，例如regedit、mmc等GUI组件，其兼容性设置也被锁死，但是为什么系统会主动询问是否提升权限？难道命令行工具是后妈养的，Windows Vista有意给它穿小鞋？
用记事本(或者其他编辑器)打开分别打开regedit.exe和sc.exe，进行仔细对比查看，发现了秘密所在：
regedit.exe和SC.exe的内容分别如下图所示。
图4
图5
从图中可以看出：
在SC.exe中有如下xml格式的语句：
level="asInvoker"
regedit.exe中有如下xml格式的语句：
level="highestAvailable"
原来UAC有一种机制，可以由应用程序的manifest(程序清单)来指定该应用程序的运行级别，可以在manifest中指定以下三种级别：
? asInvoker：继承父进程的访问令牌，这就是为什么SC.exe默认运行在standard User环境下，因为继承了CMD Shell的访问令牌。
? highestAvailable：进程可以获得它所能得到的最高级别的访问令牌。
? requireAdministrator：进程必须由管理员组成员启动，并且必须获得完全级别的访问令牌。
唯一遗憾的是，只能由Microsoft自己对SC.exe的manifest信息进行修改，如果企图借助Winhex等工具直接修改SC.exe中的Manifest信息(例如试图将其RunLevel修改为"highestAvailable")，结果就会闹和笔者一样的笑话，收到“side by side”的出错消息──都是不懂开发给整的～
这里多说一句：如果病毒等恶意程序，也利用manifest信息在其代码里添加特权标记，会不会误导最终用户？
Windows Vista的UAC功能浅析(5)
应该不会：
从Build 5308开始，Windows Vista会自动检查程序代码中的数字签名，并且在consent对话框里提供相应的警告信息。如果试图运行一个没有合法签名的程序，Windows Vista会警告说该程序没有合法的“身份证”，若要运行，后果自负。这和图5所示的情况有所区别。
图6
要了解更多的有关manifest的信息，可以参考以下的微软官方文档：
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtWindows Vista.asp
实验查验Mandatory Label SID的作用
当系统尝试启动标记为高特权的进程时，Windows Vista并非不分青红皂白，一味地弹出consent对话框要求确认。
其实这个问题在笔者的拙作《Windows Vista的UAC功能浅析(一)》中曾经提到过Windows Vista新引入了几个“古怪的SID(在本文，这些SID统称为Mandatory Label SID)：
? Medium Mandatory Level：其SID为S-1-16-8192。
? High Mandatory Level：其SID为S-1-16-12288
? System Mandatory Level：其SID为S-1-16-16384
? Low Mandatory Level：该标志主要用于保护模式的IE浏览器等进程
这三个“古怪”帐户SID，实际上就是专门用来标记访问令牌的，这些帐户既不能用于登录，也不能用于安全权限分配。
笔者在Windows Vista CTP 5308虚拟机上，分别做以下三个实验：
(1) 直接运行regedit，会弹出consent对话框确认提升权限，这时候的父进程为explorer.exe，其Mandatory Label SID为“Medium Mandatory Level”。
(2) 以“Run as administrator”方式打开一个CMD Shell，这时候CMD进程的Mandatory Label SID为“High Mandatory Level”，在其下可以打开regedit，而无需确认。
(3) 按下ctrl+alt+del组合键，在Winlogon Desktop上单击“Start Task Manager”按钮，即可弹出如下图所示的窗口，实际上就是一个taskmgr.exe进程，其Mandatory Label SID为“Medium Mandatory Level”，这里在Process Explorer里记下其PID(假设为2272)：
图7
Windows Vista的UAC功能浅析(6)
在该窗口上单击“All programs on this computer”按钮，即可弹出一个consent对话框要求确认权限的提升。确认后即可弹出任务管理器，这时候原来的taskmgr进程(PID为2272)就会被自动杀死，现在我们在Process Explorer里打开新启动的taskmgr进程的属性对话框，可以看到其父进程就是那个已经被杀死的PID为2272的进程！如下图所示。难怪需要确认是否提升权限。
图8
根据实验结果，我们可以得出以下的结论：
当我们尝试启动某个标记为需要高特权的进程时，Windows Vista会检查其“父进程”的访问令牌，并根据访问令牌里的Mandatory Label SID进行相应的判断：
? 如果是Medium Mandatory Level：则弹出consent对话框要求确认权限的提升。
? 如果是High Mandatory Level：则直接以完全权限打开目标进程，而无需确认。
? 如果是System Mandatory Level：则直接以完全权限打开目标进程，而无需确认。
这里需要注意的是，在Build 5231的Windows Vista版本里，如果按下“ctrl+alt+del”组合键，会直接弹出一个拥有完全权限的任务管理器，因为这时候任务管理器的父进程是winlogon，其Mandatory Label SID为“System Mandatory Level”。
馒头版的UAC
之所以没有给命令行添加所谓的UAC功能，猜想Microsoft考虑到使用命令行的用户大多是IT Pro，在命令行中屏蔽UAC功能，可以有效防止最终用户无意之中运行高危险的命令，例如format、BCDEDIT等，从而避免对系统的毁灭性打击。
尽管如此，笔者还是期待能够看到适用于预命令行的UAC，这里笔者“效颦”胡戈同志的“馒头”巨著，设计一个命令行版本的UAC工作界面，聊搏读者诸公一笑耳。
网友评论