前言：

     當(dāng)初弄這么個(gè)博客純粹出于蛋疼，想體會(huì)體會(huì)自己買空間，建站的樂趣?，F(xiàn)在差不多體會(huì)完了，不過也不能就這么關(guān)了吧？于是考慮著要定期整點(diǎn)東西，充實(shí)充實(shí)這個(gè)博客。按照我以往的表現(xiàn)來看，除了QQ空間目前還存活著，絕大多數(shù)我寫過的博客都半途而廢了，一來懶，二來也沒那么多東西好寫：人總不能每天都在傷春悲秋—-畢竟不是靠賣愁滋味賺錢的人，就算寫出來也意義不大，過個(gè)個(gè)把月哪還記得當(dāng)年在傷啥悲啥，就算記得，感受也不深，而且有時(shí)翻出來回味卻發(fā)現(xiàn)當(dāng)年的自己如此感性，悶騷—-燥得很，不如難得糊涂，忘了算了。

     于是考慮整點(diǎn)技術(shù)性的東西(當(dāng)然以學(xué)習(xí)筆記和某些蛋疼的技術(shù)點(diǎn)為主)，主要是我這人一般懶得記筆記，初中到現(xiàn)在唯一記筆記本的還是高三復(fù)習(xí)物理那會(huì)，主要原因是物理實(shí)在差得離譜。以至于記筆記給我的感覺很不好，而且很多東西一旦我理解了基本不會(huì)忘—-好記性不如爛筆頭，但是好的理解力就不同了，記下的東西畢竟是死的。

     言歸正傳，說這次的主題:UAC。這東西很是煩人，轉(zhuǎn)到我手里的bug和問題，估計(jì)有5%與它有關(guān)，很是煩人，于是在這一篇日志里面詳細(xì)記錄一些我理解的UAC知識(shí)。

UAC的基本概念

• 什么是UAC

       UAC即User Account Control(用戶帳號控制)，是微軟從Windows Vista開始為提高安全性而引入的一項(xiàng)新技術(shù)。用戶通過這項(xiàng)技術(shù)既可以以非管理員身份，也能夠以管理員身份執(zhí)行常見的任務(wù)，而不需要切換賬戶或者注銷。在大多數(shù)的情況下，用戶都是以標(biāo)準(zhǔn)用戶的狀態(tài)來執(zhí)行日常任務(wù)，而只有當(dāng)需要設(shè)置系統(tǒng)特定資源的操作的任務(wù)才會(huì)需要用戶以管理員的身份執(zhí)行，以此來確保進(jìn)程對系統(tǒng)的“傷害”達(dá)到最低。

• 為什么使用UAC

       簡單地說使用UAC的理由很簡單：保護(hù)系統(tǒng)資源和數(shù)據(jù)的安全。在XP時(shí)代，在系統(tǒng)安裝完畢后任何新建的賬戶都會(huì)默認(rèn)劃入系統(tǒng)管理員組，于是用戶有了安裝，卸載，修改，刪除系統(tǒng)任何地方任何數(shù)據(jù)的權(quán)限，而這正是萬惡之源。而如果能夠控制不同程序的權(quán)限，那么大部分的惡意軟件和病毒就不能起作用了。

       UAC正是基于這種思路進(jìn)行設(shè)計(jì)的：嚴(yán)格控制進(jìn)程所能獲得的權(quán)限。讓一個(gè)進(jìn)程無時(shí)無刻都擁有管理員權(quán)限是無法容忍的：一個(gè)惡意程序如果被自動(dòng)運(yùn)行于我們的系統(tǒng)，且肆無忌憚地執(zhí)行某些會(huì)進(jìn)行系統(tǒng)資源讀寫操作的代碼而不為我們所知曉那是多么恐怖的事。(XP正是這么做的)所以UAC的策略就是給予進(jìn)程盡可能低的權(quán)限，如果程序需要管理員權(quán)限則需要知會(huì)當(dāng)前用戶。同時(shí)通過一系列的措施來保障程序的正確運(yùn)行：

  1.在可行的情況下，進(jìn)行操作的權(quán)限將從系統(tǒng)管理員調(diào)整為標(biāo)準(zhǔn)用戶。(給予最低權(quán)限)

  2.利用虛擬化技術(shù)在沒有獲得系統(tǒng)管理員權(quán)限的情況下協(xié)助程序運(yùn)行。(例如對注冊表訪問的重定向，保證舊版本程序的兼容性)

  3.對程序進(jìn)行再處理，這樣用戶帳戶控制功能就可以知道在什么情況下需要系統(tǒng)管理員權(quán)限。(可執(zhí)行文件的UAC頭，來控制和判斷程序所需要的權(quán)限，默認(rèn)是asInvoker或None)

  4.確保在系統(tǒng)管理員權(quán)限下運(yùn)行的程序和在標(biāo)準(zhǔn)用戶權(quán)限下運(yùn)行的程序是分離的(如UIPI)

• UAC帶來的影響

       對普通用戶而言，UAC的引入可能并沒有帶來多大的影響，更多的可能只是在啟動(dòng)特定程序的時(shí)候有時(shí)候會(huì)跳出提示通知用戶以管理員身份運(yùn)行，僅此而已。但是這個(gè)地方有個(gè)比較尷尬的問題：UAC(或者其他類似的安全措施)是基于如下假設(shè)的：

       1.個(gè)人用戶對于系統(tǒng)安全有一定的認(rèn)識(shí)，能夠分辨哪些程序是好的，哪些是壞的。但是實(shí)際上對于大多數(shù)網(wǎng)民來說，這個(gè)假設(shè)未必成立，即使惡意軟件跳出提示要以管理員身份運(yùn)行，他們往往也是點(diǎn)確定讓它運(yùn)行。那么UAC的意義又在哪呢？

      2.企業(yè)用戶可以對系統(tǒng)安全一無所知，但是考慮到企業(yè)內(nèi)部會(huì)有IT部門幫忙進(jìn)行安全屬性配置和軟硬件的安裝，UAC對他們來說是很有效的：只需要分配給他們標(biāo)準(zhǔn)用戶帳號進(jìn)行日常任務(wù)處理既可。但現(xiàn)實(shí)情況卻是： 如果企業(yè)用戶安裝軟件或其他需要管理員權(quán)限的事務(wù)都需要知會(huì)IT，那整個(gè)溝通成本太高，不現(xiàn)實(shí)。更何況很多軟件產(chǎn)品都有不兼容UAC的問題。(比如部分公司開發(fā)的程序?yàn)榱?#8220;繞過”UAC，直接把程序設(shè)為必須以管理員帳戶運(yùn)行)

       對于開發(fā)人員來說可能影響會(huì)更大。如何讓自己新老程序兼容和適應(yīng)UAC的規(guī)則是一個(gè)不大不小的課題。

    

  開發(fā)所需要了解的UAC

• UAC的基本實(shí)現(xiàn)原理

       在Windows中有兩項(xiàng)比較重要的概念:ACL和Access Token。ACL即Access Control List(直譯成:訪問控制列表)，對于Wdinows中的所有資源來說都會(huì)有自己的ACL，這個(gè)列表決定了這個(gè)資源可以被具有哪些權(quán)限的用戶/進(jìn)程所訪問。而Access Token即用戶的訪問令牌，這決定了用戶對資源的訪問屬性。在Vista之前的系統(tǒng)中，如果用戶使用了標(biāo)準(zhǔn)用戶(如XP中所謂的受限用戶)，用戶就會(huì)得到一個(gè)和之相對應(yīng)的Access Token，只能訪問和修改有限的用戶資源。但只要用戶用了管理員組的帳號進(jìn)行登入，用戶就能夠獲取一個(gè)所謂的"Full Access Token"，即可以獲取到對任意資源的訪問權(quán)。這顯然是多余而且不安全的，于是從Vista起的UAC就做了如下的調(diào)整：

       1.如果用戶是標(biāo)準(zhǔn)用戶，那么還是和以前一樣分配給用戶一個(gè)標(biāo)準(zhǔn)的訪問令牌。

       2.而如果用戶是以管理員用戶登入，則有所不同：系統(tǒng)不再是和以前一樣分配個(gè)萬能的訪問令牌，而是生成兩份訪問令牌：一個(gè)完整的管理員訪問令牌和一份經(jīng)“和諧”的標(biāo)準(zhǔn)用戶令牌。在默認(rèn)的情況下，管理員權(quán)限會(huì)被移除(或者說被保存到某個(gè)地方，等用戶主動(dòng)請求)，而用戶只拿到了他所需要的標(biāo)準(zhǔn)用戶訪問權(quán)限，并通過它創(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)限可能過低，而不在某些敏感資源的ACL允許范圍。那么從技術(shù)角度來說，搞清楚哪些資源是所謂的敏感資源就很重要—-知己知彼，百戰(zhàn)不殆。從Wiki摘抄的需要UAC授權(quán)的操作:

  • 配置Windows Update
  • 增加或刪除用戶帳戶
  • 改變用戶的帳戶類型
  • 改變UAC設(shè)置
  • 安裝ActiveX
  • 安裝或移除程序
  • 安裝設(shè)備驅(qū)動(dòng)程序
  • 設(shè)置家長控制
  • 將文件移動(dòng)或復(fù)制到Program Files或Windows目錄
  • 查看其他用戶文件夾

        基本上，只要有涉及到訪問系統(tǒng)磁盤的根目錄（例如C:），訪問Windows目錄，Windows系統(tǒng)目錄，Program Files目錄，訪問Windows安全信息以及讀寫系統(tǒng)登錄數(shù)據(jù)庫（Registry）的程序訪問動(dòng)作，都會(huì)需要通過UAC的認(rèn)證。

• UAC帶來的程序啟動(dòng)選項(xiàng)的變化和注意事項(xiàng)

        對于普通用戶來講，UAC最直觀的感受就是在很多程序圖標(biāo)多了個(gè)小盾，且雙擊后會(huì)出來個(gè)用戶賬戶控制的窗口。而對于技術(shù)人員來說當(dāng)然更需要關(guān)心真正的內(nèi)幕：啟動(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)方式請求當(dāng)前賬戶可以獲取到的最高權(quán)限：如果本身是管理員組內(nèi)成員，則可以得到完整的管理員訪問令牌，呼風(fēng)喚雨。而如果是標(biāo)準(zhǔn)用戶則只能得到它這個(gè)用戶能夠得到的最高權(quán)限。(具體如何設(shè)置程序啟動(dòng)選項(xiàng)在下面的Tips中繼續(xù)說)上一幅MSDN提供的開啟UAC狀態(tài)下程序啟動(dòng)的流程圖：

  

• MS為支持UAC引入的新技術(shù)和注意事項(xiàng)

     為實(shí)現(xiàn)UAC的所有功能，微軟可謂煞費(fèi)苦心，整了很多新的技術(shù)和新概念出來。(雖然個(gè)人覺得這個(gè)技術(shù)對于一般用戶來說還是很雞肋)下面就羅列一部分我們平常開發(fā)中可能會(huì)碰到或者遇到的技術(shù)：

      1.Installer Dection

       這個(gè)技術(shù)最大的作用是為了兼容以前的以前版本系統(tǒng)中的程序(尤其是安裝程序，顧名思義嘛)，在UAC下安裝程序做的很多事情可能都是十惡不赦，需要最高權(quán)限的(如寫注冊表，寫敏感文件目錄)，而舊版本的程序壓根沒有做任何特殊處理(或者說是只是填充了一些默認(rèn)信息)，所以一種行之有效的安裝程序檢測技術(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沒有做任何處理卻一直要求能夠以管理員權(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ì)出來的技術(shù)。簡單地來說(這個(gè)只能簡單來說了，具體的原理沒有相應(yīng)的參考資料)，就是對老程序所進(jìn)行的“非法”的 訪問系統(tǒng)敏感數(shù)據(jù)進(jìn)行重定向，可以分為文件虛擬化和注冊表虛擬化。當(dāng)用戶對一個(gè)需要管理員權(quán)限才能夠訪問的文件目錄或者注冊表項(xiàng)進(jìn)行讀寫都會(huì)被重定向。

如左圖，用戶對%ProgramFiles%的讀寫會(huì)被定向到%LocalAppData%VirtualStore下，而對于HKLMSoftware的讀寫會(huì)被重定向到HKCUSoftwareClassesVirtualStore下。

   特別需要注意的是：因?yàn)樵赬P下養(yǎng)成的習(xí)慣，我們對于注冊表的讀寫很多直接就是用KEY_ALL_ACCESS的選項(xiàng)，而到了Vista和Win7后，因?yàn)榉峙浣o用戶的權(quán)限低了(即使管理員帳號登入拿到的權(quán)限也是經(jīng)過“和諧”的，上文已經(jīng)提到)，對注冊表的訪問需要按需設(shè)置，如果只是讀取一些注冊表項(xiàng)值就沒必要設(shè)置ALL_ACCESS，大多時(shí)候READ甚至QUERY的權(quán)限就夠了。

       3.UIPI

       這是唯一一項(xiàng)純粹是出于提高安全性而不是確保兼容性引進(jìn)的新技術(shù)。UIPI即User Interface Privilege Isolation，直譯過來就是用戶界面特權(quán)隔離。在XP時(shí)代到處充斥著各種消息粉碎攻擊，最典型的就是通過發(fā)送WM_CLOSE消息使得接收者退出或者發(fā)送WM_SETTEXT給其他窗口輸入信息(QQ尾巴算是這種攻擊的典型應(yīng)用)。大多數(shù)程序?qū)τ谶@種攻擊都是無能為了，很多程序(比如QQ，POPO之類的IM)往往只能自己對信息做特殊的過濾和判斷來防范，很是繁瑣。而UIPI的基本作用就是使進(jìn)程可以攔截接受比自身進(jìn)程MIC等級低的進(jìn)程發(fā)來的消息。在UIPI開啟的情況下，只要是低MIC等級的進(jìn)程向高M(jìn)IC等級的進(jìn)程發(fā)送消息，所有高于WM_USER的消息都默認(rèn)被攔截，而低于WM_USER的消息也只有部分能夠被選擇性地發(fā)送成功，一些比較危險(xiǎn)的消息也是直接被攔截掉。

      所謂MIC即Mandatory Integrity Control，全稱為強(qiáng)制完整性控制，是微軟對Vista以上的系統(tǒng)做的安全性拓展，主要基于Biba模型。其核心在于達(dá)到"no write up，no read down"的效果。(這個(gè)no read down貌似在Vista里面反映得不是很明顯，或者是沒怎么注意到吧)在Vista和Win7里,MIC共分為6級:不可用，低級，中級，高級，系統(tǒng)級別和手保護(hù)級別。一般我們的進(jìn)程包括Explorer.exe是中級，通過管理員身份運(yùn)行的進(jìn)程為高級，而值得注意的是IE的MIC級別是低級別—-這個(gè)理由就很明顯了，不贅述，娃哈哈。

      特別聲明，某個(gè)賤人碰到的問題就和UIPI有關(guān)，誰叫IE的MIC等級低呢，可憐的XX寶……

• 個(gè)人總結(jié)的一些關(guān)于UAC的Tips

    

      1.何時(shí)需要提高進(jìn)程的權(quán)限?

       答案是：在進(jìn)程啟動(dòng)的時(shí)候。這個(gè)問題貌似很SB，卻是很多bug會(huì)產(chǎn)生的根源。在程序運(yùn)行的過程是不能再對當(dāng)前進(jìn)程進(jìn)行提權(quán)的：如果程序執(zhí)行過程中和操作系統(tǒng)說：哥要提權(quán)。這個(gè)時(shí)候系統(tǒng)是不會(huì)理你的，當(dāng)然也沒有相應(yīng)的API提供。

   

      2.如何設(shè)置一個(gè)程序的啟動(dòng)選項(xiàng)

      一種比較簡單的方法就是通過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)為你的程序是安裝程序，給加上小盾盾。不過個(gè)人感覺前面的5項(xiàng)都不太靠譜。最標(biāo)準(zhǔn)的做法是在可執(zhí)行文件中嵌入U(xiǎn)AC頭。在VS08之后的工程選項(xiàng)Manifest File設(shè)置里面有了對啟動(dòng)等級的設(shè)置。而05之前則需要自己建立一個(gè)manifest文件，并通過Mt.exe向目標(biāo)進(jìn)程插入manifest。詳見《Create and Embed an Application Manifest (UAC)》

   

       3.UAC對文件系統(tǒng)和窗口消息的影響

       因?yàn)閷KLM等注冊表項(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è)問題)

       UIPI的存在使得對于進(jìn)程間窗口消息傳遞的控制更嚴(yán)格了，稍不留神一個(gè)消息可能就被吃掉了，所以進(jìn)程間通信最萬不得已的情況還是盡量少使用窗口消息—-安全性和可靠性太差。(在管理員權(quán)限環(huán)境上下文中，拖曳消息會(huì)被UIPI給屏蔽掉……)

       4.降權(quán)的需求和實(shí)現(xiàn)

       降權(quán)的需求來自于更新程序：更新程序?yàn)楸ＷC能夠正常運(yùn)行往往是以管理員身份運(yùn)行，但這樣有個(gè)問題， 當(dāng)更新成功后更新進(jìn)程啟動(dòng)主程序會(huì)將自己的權(quán)限傳遞下去，這會(huì)帶來兩大麻煩：

      1.主程序獲得了不該有權(quán)限，

       2.主程序的用戶環(huán)境變量上下文可能被修改了。

       第一項(xiàng)問題可能不大，而第二項(xiàng)就比較要命了：主程序在更新后讀取的文件路徑都會(huì)變成管理員相關(guān)的而非當(dāng)前用戶的(通過查看進(jìn)程管理器可以發(fā)現(xiàn)主程序也變成了管理員進(jìn)程)    

       推薦的做法是在程序啟動(dòng)更新程序進(jìn)行更新的同時(shí)保證有一個(gè)當(dāng)前用戶權(quán)限下的監(jiān)控程序存在，在更新完畢后通過監(jiān)控程序來啟動(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》，基本原理還是通過一個(gè)已存在的當(dāng)前用戶權(quán)限的進(jìn)程來啟動(dòng)主程序，不同的是采用了進(jìn)程內(nèi)代碼注入的方法，比較巧妙，但不推薦。