http://www.xiangwangfeng.com/2010/10/20/uac%E7%9A%84%E5%89%8D%E4%B8%96%E4%BB%8A%E7%94%9F/
前言：
當(dāng)初弄這么個(gè)博客純粹出于蛋疼，想體會(huì)體會(huì)自己買空間，建站的樂(lè)趣。現(xiàn)在差不多體會(huì)完了，不過(guò)也不能就這么關(guān)了吧？于是考慮著要定期整點(diǎn)東西，充實(shí)充實(shí)這個(gè)博客。按照我以往的表現(xiàn)來(lái)看，除了QQ空間目前還存活著，絕大多數(shù)我寫過(guò)的博客都半途而廢了，一來(lái)懶，二來(lái)也沒(méi)那么多東西好寫：人總不能每天都在傷春悲秋—-畢竟不是靠賣愁滋味賺錢的人，就算寫出來(lái)也意義不大，過(guò)個(gè)個(gè)把月哪還記得當(dāng)年在傷啥悲啥，就算記得，感受也不深，而且有時(shí)翻出來(lái)回味卻發(fā)現(xiàn)當(dāng)年的自己如此感性，悶騷—-燥得很，不如難得糊涂，忘了算了。
于是考慮整點(diǎn)技術(shù)性的東西(當(dāng)然以學(xué)習(xí)筆記和某些蛋疼的技術(shù)點(diǎn)為主)，主要是我這人一般懶得記筆記，初中到現(xiàn)在唯一記筆記本的還是高三復(fù)習(xí)物理那會(huì)，主要原因是物理實(shí)在差得離譜。以至于記筆記給我的感覺(jué)很不好，而且很多東西一旦我理解了基本不會(huì)忘—-好記性不如爛筆頭，但是好的理解力就不同了，記下的東西畢竟是死的。
言歸正傳，說(shuō)這次的主題:UAC。這東西很是煩人，轉(zhuǎn)到我手里的bug和問(wèn)題，估計(jì)有5%與它有關(guān)，很是煩人，于是在這一篇日志里面詳細(xì)記錄一些我理解的UAC知識(shí)。
UAC的基本概念
什么是UAC
UAC即User Account Control(用戶帳號(hào)控制)，是微軟從Windows Vista開始為提高安全性而引入的一項(xiàng)新技術(shù)。用戶通過(guò)這項(xiàng)技術(shù)既可以以非管理員身份，也能夠以管理員身份執(zhí)行常見(jiàn)的任務(wù)，而不需要切換賬戶或者注銷。在大多數(shù)的情況下，用戶都是以標(biāo)準(zhǔn)用戶的狀態(tài)來(lái)執(zhí)行日常任務(wù)，而只有當(dāng)需要設(shè)置系統(tǒng)特定資源的操作的任務(wù)才會(huì)需要用戶以管理員的身份執(zhí)行，以此來(lái)確保進(jìn)程對(duì)系統(tǒng)的“傷害”達(dá)到最低。
為什么使用UAC
簡(jiǎn)單地說(shuō)使用UAC的理由很簡(jiǎn)單：保護(hù)系統(tǒng)資源和數(shù)據(jù)的安全。在XP時(shí)代，在系統(tǒng)安裝完畢后任何新建的賬戶都會(huì)默認(rèn)劃入系統(tǒng)管理員組，于是用戶有了安裝，卸載，修改，刪除系統(tǒng)任何地方任何數(shù)據(jù)的權(quán)限，而這正是萬(wàn)惡之源。而如果能夠控制不同程序的權(quán)限，那么大部分的惡意軟件和病毒就不能起作用了。
UAC正是基于這種思路進(jìn)行設(shè)計(jì)的：嚴(yán)格控制進(jìn)程所能獲得的權(quán)限。讓一個(gè)進(jìn)程無(wú)時(shí)無(wú)刻都擁有管理員權(quán)限是無(wú)法容忍的：一個(gè)惡意程序如果被自動(dòng)運(yùn)行于我們的系統(tǒng)，且肆無(wú)忌憚地執(zhí)行某些會(huì)進(jìn)行系統(tǒng)資源讀寫操作的代碼而不為我們所知曉那是多么恐怖的事。(XP正是這么做的)所以UAC的策略就是給予進(jìn)程盡可能低的權(quán)限，如果程序需要管理員權(quán)限則需要知會(huì)當(dāng)前用戶。同時(shí)通過(guò)一系列的措施來(lái)保障程序的正確運(yùn)行：
1.在可行的情況下，進(jìn)行操作的權(quán)限將從系統(tǒng)管理員調(diào)整為標(biāo)準(zhǔn)用戶。(給予最低權(quán)限)
2.利用虛擬化技術(shù)在沒(méi)有獲得系統(tǒng)管理員權(quán)限的情況下協(xié)助程序運(yùn)行。(例如對(duì)注冊(cè)表訪問(wèn)的重定向，保證舊版本程序的兼容性)
3.對(duì)程序進(jìn)行再處理，這樣用戶帳戶控制功能就可以知道在什么情況下需要系統(tǒng)管理員權(quán)限。(可執(zhí)行文件的UAC頭，來(lái)控制和判斷程序所需要的權(quán)限，默認(rèn)是asInvoker或None)
4.確保在系統(tǒng)管理員權(quán)限下運(yùn)行的程序和在標(biāo)準(zhǔn)用戶權(quán)限下運(yùn)行的程序是分離的(如UIPI)
UAC帶來(lái)的影響
對(duì)普通用戶而言，UAC的引入可能并沒(méi)有帶來(lái)多大的影響，更多的可能只是在啟動(dòng)特定程序的時(shí)候有時(shí)候會(huì)跳出提示通知用戶以管理員身份運(yùn)行，僅此而已。但是這個(gè)地方有個(gè)比較尷尬的問(wèn)題：UAC(或者其他類似的安全措施)是基于如下假設(shè)的：
1.個(gè)人用戶對(duì)于系統(tǒng)安全有一定的認(rèn)識(shí)，能夠分辨哪些程序是好的，哪些是壞的。但是實(shí)際上對(duì)于大多數(shù)網(wǎng)民來(lái)說(shuō)，這個(gè)假設(shè)未必成立，即使惡意軟件跳出提示要以管理員身份運(yùn)行，他們往往也是點(diǎn)確定讓它運(yùn)行。那么UAC的意義又在哪呢？
2.企業(yè)用戶可以對(duì)系統(tǒng)安全一無(wú)所知，但是考慮到企業(yè)內(nèi)部會(huì)有IT部門幫忙進(jìn)行安全屬性配置和軟硬件的安裝，UAC對(duì)他們來(lái)說(shuō)是很有效的：只需要分配給他們標(biāo)準(zhǔn)用戶帳號(hào)進(jìn)行日常任務(wù)處理既可。但現(xiàn)實(shí)情況卻是： 如果企業(yè)用戶安裝軟件或其他需要管理員權(quán)限的事務(wù)都需要知會(huì)IT，那整個(gè)溝通成本太高，不現(xiàn)實(shí)。更何況很多軟件產(chǎn)品都有不兼容UAC的問(wèn)題。(比如部分公司開發(fā)的程序?yàn)榱?#8220;繞過(guò)”UAC，直接把程序設(shè)為必須以管理員帳戶運(yùn)行)
對(duì)于開發(fā)人員來(lái)說(shuō)可能影響會(huì)更大。如何讓自己新老程序兼容和適應(yīng)UAC的規(guī)則是一個(gè)不大不小的課題。
開發(fā)所需要了解的UAC
UAC的基本實(shí)現(xiàn)原理
在Windows中有兩項(xiàng)比較重要的概念:ACL和Access Token。ACL即Access Control List(直譯成:訪問(wèn)控制列表)，對(duì)于Wdinows中的所有資源來(lái)說(shuō)都會(huì)有自己的ACL，這個(gè)列表決定了這個(gè)資源可以被具有哪些權(quán)限的用戶/進(jìn)程所訪問(wèn)。而Access Token即用戶的訪問(wèn)令牌，這決定了用戶對(duì)資源的訪問(wèn)屬性。在Vista之前的系統(tǒng)中，如果用戶使用了標(biāo)準(zhǔn)用戶(如XP中所謂的受限用戶)，用戶就會(huì)得到一個(gè)和之相對(duì)應(yīng)的Access Token，只能訪問(wèn)和修改有限的用戶資源。但只要用戶用了管理員組的帳號(hào)進(jìn)行登入，用戶就能夠獲取一個(gè)所謂的"Full Access Token"，即可以獲取到對(duì)任意資源的訪問(wèn)權(quán)。這顯然是多余而且不安全的，于是從Vista起的UAC就做了如下的調(diào)整：
1.如果用戶是標(biāo)準(zhǔn)用戶，那么還是和以前一樣分配給用戶一個(gè)標(biāo)準(zhǔn)的訪問(wèn)令牌。
2.而如果用戶是以管理員用戶登入，則有所不同：系統(tǒng)不再是和以前一樣分配個(gè)萬(wàn)能的訪問(wèn)令牌，而是生成兩份訪問(wèn)令牌：一個(gè)完整的管理員訪問(wèn)令牌和一份經(jīng)“和諧”的標(biāo)準(zhǔn)用戶令牌。在默認(rèn)的情況下，管理員權(quán)限會(huì)被移除(或者說(shuō)被保存到某個(gè)地方，等用戶主動(dòng)請(qǐng)求)，而用戶只拿到了他所需要的標(biāo)準(zhǔn)用戶訪問(wèn)權(quán)限，并通過(guò)它創(chuàng)建了Explorer.exe程序，并以其為父進(jìn)程創(chuàng)建所有基于標(biāo)準(zhǔn)用戶的進(jìn)程。
具體的流程可參考如圖(從MSDN上盜得):
UAC影響到的資源
從上文我們已經(jīng)可以知道UAC會(huì)使得我們的程序運(yùn)行在一個(gè)盡可能低的權(quán)限下，而這個(gè)權(quán)限可能過(guò)低，而不在某些敏感資源的ACL允許范圍。那么從技術(shù)角度來(lái)說(shuō)，搞清楚哪些資源是所謂的敏感資源就很重要—-知己知彼，百戰(zhàn)不殆。從Wiki摘抄的需要UAC授權(quán)的操作:
- 配置Windows Update
- 增加或刪除用戶帳戶
- 改變用戶的帳戶類型
- 改變UAC設(shè)置
- 安裝ActiveX
- 安裝或移除程序
- 安裝設(shè)備驅(qū)動(dòng)程序
- 設(shè)置家長(zhǎng)控制
- 將文件移動(dòng)或復(fù)制到Program Files或Windows目錄
- 查看其他用戶文件夾
基本上，只要有涉及到訪問(wèn)系統(tǒng)磁盤的根目錄（例如C:），訪問(wèn)Windows目錄，Windows系統(tǒng)目錄，Program Files目錄，訪問(wèn)Windows安全信息以及讀寫系統(tǒng)登錄數(shù)據(jù)庫(kù)（Registry）的程序訪問(wèn)動(dòng)作，都會(huì)需要通過(guò)UAC的認(rèn)證。
UAC帶來(lái)的程序啟動(dòng)選項(xiàng)的變化和注意事項(xiàng)
對(duì)于普通用戶來(lái)講，UAC最直觀的感受就是在很多程序圖標(biāo)多了個(gè)小盾，且雙擊后會(huì)出來(lái)個(gè)用戶賬戶控制的窗口。而對(duì)于技術(shù)人員來(lái)說(shuō)當(dāng)然更需要關(guān)心真正的內(nèi)幕：?jiǎn)?dòng)的時(shí)候進(jìn)程做了提權(quán)的動(dòng)作，獲取了更高權(quán)限的用戶令牌。(而這又可能導(dǎo)致這個(gè)進(jìn)程的用戶相關(guān)上下文直接改變，當(dāng)然這是后話)在Vista以后的程序在默認(rèn)情況下會(huì)有3種啟動(dòng)選項(xiàng):asInvoker(None)，highestAvailable和requireAdministrator。其中highestAvailable最不為大家熟知：這種啟動(dòng)方式請(qǐng)求當(dāng)前賬戶可以獲取到的最高權(quán)限：如果本身是管理員組內(nèi)成員，則可以得到完整的管理員訪問(wèn)令牌，呼風(fēng)喚雨。而如果是標(biāo)準(zhǔn)用戶則只能得到它這個(gè)用戶能夠得到的最高權(quán)限。(具體如何設(shè)置程序啟動(dòng)選項(xiàng)在下面的Tips中繼續(xù)說(shuō))上一幅MSDN提供的開啟UAC狀態(tài)下程序啟動(dòng)的流程圖：
MS為支持UAC引入的新技術(shù)和注意事項(xiàng)
為實(shí)現(xiàn)UAC的所有功能，微軟可謂煞費(fèi)苦心，整了很多新的技術(shù)和新概念出來(lái)。(雖然個(gè)人覺(jué)得這個(gè)技術(shù)對(duì)于一般用戶來(lái)說(shuō)還是很雞肋)下面就羅列一部分我們平常開發(fā)中可能會(huì)碰到或者遇到的技術(shù)：
1.Installer Dection
這個(gè)技術(shù)最大的作用是為了兼容以前的以前版本系統(tǒng)中的程序(尤其是安裝程序，顧名思義嘛)，在UAC下安裝程序做的很多事情可能都是十惡不赦，需要最高權(quán)限的(如寫注冊(cè)表，寫敏感文件目錄)，而舊版本的程序壓根沒(méi)有做任何特殊處理(或者說(shuō)是只是填充了一些默認(rèn)信息)，所以一種行之有效的安裝程序檢測(cè)技術(shù)是很必要的，否則很多程序安裝都不成功，更毋論運(yùn)行了。
MSDN上總結(jié)了一些Installer Dection的原則:
1.文件名包含關(guān)鍵字:"install”,“setup”,"update”等關(guān)鍵字
2.在版本資源的以下字段內(nèi)包含關(guān)鍵字:Vendor,CompanyName,ProductName,File Description,Original Filename,Internal Name,Export Name。(這兩條應(yīng)該是最SB卻又最有效的一個(gè)方法，當(dāng)年閃電郵的UpdateExec沒(méi)有做任何處理卻一直要求能夠以管理員權(quán)限運(yùn)行的事讓我迷茫了很久)
3.可執(zhí)行文件的manifest文件中包含關(guān)鍵字
4.在鏈接到可執(zhí)行文件的特定String Table中包含關(guān)鍵字 (這個(gè)我很迷茫，求解釋)
5.鏈接到可執(zhí)行文件的資源文件數(shù)據(jù)包含關(guān)鍵屬性
6.可執(zhí)行文件包含特定的字節(jié)序列(這個(gè)意思應(yīng)該是用戶在manifest中寫入特定屬性，然后鏈接到可執(zhí)行文件中并填充了某個(gè)字段—-現(xiàn)在基本上所有的安裝程序/需要提權(quán)的程序都是這么做的)
2.Virtualization(虛擬化)
這是一項(xiàng)比較扯同時(shí)也是為了保證兼容性設(shè)計(jì)出來(lái)的技術(shù)。簡(jiǎn)單地來(lái)說(shuō)(這個(gè)只能簡(jiǎn)單來(lái)說(shuō)了，具體的原理沒(méi)有相應(yīng)的參考資料)，就是對(duì)老程序所進(jìn)行的“非法”的 訪問(wèn)系統(tǒng)敏感數(shù)據(jù)進(jìn)行重定向，可以分為文件虛擬化和注冊(cè)表虛擬化。當(dāng)用戶對(duì)一個(gè)需要管理員權(quán)限才能夠訪問(wèn)的文件目錄或者注冊(cè)表項(xiàng)進(jìn)行讀寫都會(huì)被重定向。
如左圖，用戶對(duì)%ProgramFiles%的讀寫會(huì)被定向到%LocalAppData%VirtualStore下，而對(duì)于HKLMSoftware的讀寫會(huì)被重定向到HKCUSoftwareClassesVirtualStore下。
特別需要注意的是：因?yàn)樵赬P下養(yǎng)成的習(xí)慣，我們對(duì)于注冊(cè)表的讀寫很多直接就是用KEY_ALL_ACCESS的選項(xiàng)，而到了Vista和Win7后，因?yàn)榉峙浣o用戶的權(quán)限低了(即使管理員帳號(hào)登入拿到的權(quán)限也是經(jīng)過(guò)“和諧”的，上文已經(jīng)提到)，對(duì)注冊(cè)表的訪問(wèn)需要按需設(shè)置，如果只是讀取一些注冊(cè)表項(xiàng)值就沒(méi)必要設(shè)置ALL_ACCESS，大多時(shí)候READ甚至QUERY的權(quán)限就夠了。
3.UIPI
這是唯一一項(xiàng)純粹是出于提高安全性而不是確保兼容性引進(jìn)的新技術(shù)。UIPI即User Interface Privilege Isolation，直譯過(guò)來(lái)就是用戶界面特權(quán)隔離。在XP時(shí)代到處充斥著各種消息粉碎攻擊，最典型的就是通過(guò)發(fā)送WM_CLOSE消息使得接收者退出或者發(fā)送WM_SETTEXT給其他窗口輸入信息(QQ尾巴算是這種攻擊的典型應(yīng)用)。大多數(shù)程序?qū)τ谶@種攻擊都是無(wú)能為了，很多程序(比如QQ，POPO之類的IM)往往只能自己對(duì)信息做特殊的過(guò)濾和判斷來(lái)防范，很是繁瑣。而UIPI的基本作用就是使進(jìn)程可以攔截接受比自身進(jìn)程MIC等級(jí)低的進(jìn)程發(fā)來(lái)的消息。在UIPI開啟的情況下，只要是低MIC等級(jí)的進(jìn)程向高M(jìn)IC等級(jí)的進(jìn)程發(fā)送消息，所有高于WM_USER的消息都默認(rèn)被攔截，而低于WM_USER的消息也只有部分能夠被選擇性地發(fā)送成功，一些比較危險(xiǎn)的消息也是直接被攔截掉。
所謂MIC即Mandatory Integrity Control，全稱為強(qiáng)制完整性控制，是微軟對(duì)Vista以上的系統(tǒng)做的安全性拓展，主要基于Biba模型。其核心在于達(dá)到"no write up，no read down"的效果。(這個(gè)no read down貌似在Vista里面反映得不是很明顯，或者是沒(méi)怎么注意到吧)在Vista和Win7里,MIC共分為6級(jí):不可用，低級(jí)，中級(jí)，高級(jí)，系統(tǒng)級(jí)別和手保護(hù)級(jí)別。一般我們的進(jìn)程包括Explorer.exe是中級(jí)，通過(guò)管理員身份運(yùn)行的進(jìn)程為高級(jí)，而值得注意的是IE的MIC級(jí)別是低級(jí)別—-這個(gè)理由就很明顯了，不贅述，娃哈哈。
特別聲明，某個(gè)賤人碰到的問(wèn)題就和UIPI有關(guān)，誰(shuí)叫IE的MIC等級(jí)低呢，可憐的XX寶……
個(gè)人總結(jié)的一些關(guān)于UAC的Tips
1.何時(shí)需要提高進(jìn)程的權(quán)限?
答案是：在進(jìn)程啟動(dòng)的時(shí)候。這個(gè)問(wèn)題貌似很SB，卻是很多bug會(huì)產(chǎn)生的根源。在程序運(yùn)行的過(guò)程是不能再對(duì)當(dāng)前進(jìn)程進(jìn)行提權(quán)的：如果程序執(zhí)行過(guò)程中和操作系統(tǒng)說(shuō)：哥要提權(quán)。這個(gè)時(shí)候系統(tǒng)是不會(huì)理你的，當(dāng)然也沒(méi)有相應(yīng)的API提供。
2.如何設(shè)置一個(gè)程序的啟動(dòng)選項(xiàng)
一種比較簡(jiǎn)單的方法就是通過(guò)API啟動(dòng)某個(gè)進(jìn)程的時(shí)候帶上啟動(dòng)選項(xiàng)，比如ShellExecuteEx有個(gè)runas選項(xiàng)
而如果需要讓一個(gè)程序一直以管理員身份啟動(dòng)的方法就很多了：上文提到的Installer Dection的原則大多可以滿足這個(gè)需求，讓系統(tǒng)認(rèn)為你的程序是安裝程序，給加上小盾盾。不過(guò)個(gè)人感覺(jué)前面的5項(xiàng)都不太靠譜。最標(biāo)準(zhǔn)的做法是在可執(zhí)行文件中嵌入U(xiǎn)AC頭。在VS08之后的工程選項(xiàng)Manifest File設(shè)置里面有了對(duì)啟動(dòng)等級(jí)的設(shè)置。而05之前則需要自己建立一個(gè)manifest文件，并通過(guò)Mt.exe向目標(biāo)進(jìn)程插入manifest。詳見(jiàn)《Create and Embed an Application Manifest (UAC)》
3.UAC對(duì)文件系統(tǒng)和窗口消息的影響
因?yàn)閷?duì)HKLM等注冊(cè)表項(xiàng)和系統(tǒng)文件目錄的讀寫會(huì)被重定向，所以盡量不要在非管理權(quán)限進(jìn)程中進(jìn)行這方面的讀寫—-合理安排用戶數(shù)據(jù)的存儲(chǔ)，而不是像以前一樣所有數(shù)據(jù)都存在程序目錄下。(當(dāng)然也有猥瑣的方法可以繞開這個(gè)限制，但是不推薦)
啟動(dòng)一個(gè)需要提權(quán)的進(jìn)程后需要注意這個(gè)進(jìn)程的環(huán)境變量上下文：標(biāo)準(zhǔn)用戶下以管理員身份啟動(dòng)某進(jìn)程后，該進(jìn)程的環(huán)境變量上下文是管理員身份相關(guān)的，而非當(dāng)前標(biāo)準(zhǔn)用戶的。(登入用戶本身是管理員組成員不會(huì)有這個(gè)問(wèn)題)
UIPI的存在使得對(duì)于進(jìn)程間窗口消息傳遞的控制更嚴(yán)格了，稍不留神一個(gè)消息可能就被吃掉了，所以進(jìn)程間通信最萬(wàn)不得已的情況還是盡量少使用窗口消息—-安全性和可靠性太差。(在管理員權(quán)限環(huán)境上下文中，拖曳消息會(huì)被UIPI給屏蔽掉……)
4.降權(quán)的需求和實(shí)現(xiàn)
降權(quán)的需求來(lái)自于更新程序：更新程序?yàn)楸ＷC能夠正常運(yùn)行往往是以管理員身份運(yùn)行，但這樣有個(gè)問(wèn)題， 當(dāng)更新成功后更新進(jìn)程啟動(dòng)主程序會(huì)將自己的權(quán)限傳遞下去，這會(huì)帶來(lái)兩大麻煩：
1.主程序獲得了不該有權(quán)限，
2.主程序的用戶環(huán)境變量上下文可能被修改了。
第一項(xiàng)問(wèn)題可能不大，而第二項(xiàng)就比較要命了：主程序在更新后讀取的文件路徑都會(huì)變成管理員相關(guān)的而非當(dāng)前用戶的(通過(guò)查看進(jìn)程管理器可以發(fā)現(xiàn)主程序也變成了管理員進(jìn)程)
推薦的做法是在程序啟動(dòng)更新程序進(jìn)行更新的同時(shí)保證有一個(gè)當(dāng)前用戶權(quán)限下的監(jiān)控程序存在，在更新完畢后通過(guò)監(jiān)控程序來(lái)啟動(dòng)主程序。
當(dāng)然也有比較猥瑣的做法，可以參考《High elevation can be bad for your application: How to start a non-elevated process at the end of the installation》，基本原理還是通過(guò)一個(gè)已存在的當(dāng)前用戶權(quán)限的進(jìn)程來(lái)啟動(dòng)主程序，不同的是采用了進(jìn)程內(nèi)代碼注入的方法，比較巧妙，但不推薦。