Win7操作系統用戶帳戶控制功能詳解收獲很多的( 五 )


自動提升與UAC 的目標:
那么 , 所有特殊自動提升規則背后的原理是什么?選擇要自動提升哪些程序以及不自動提升哪些程序是由以下問題確定的:“應用程序開發人員是否能夠利用自動提升無意間或不費力地依賴于管理權限?”由于可以使用 Cmd.exe 通過命令行參數來執行批處理腳本 , 并且普通用戶不需要以提升方式運行命令提示符(大多數用戶甚至不知道命令提示符是什么) , 因此未將 Cmd.exe 列入自動提升的清單 。 同樣 , 承載控制面板插件的可執行文件 Rundll32.exe 在 Windows 7 的最終版本中也未自動提升 , 因為對于任何常見管理任務而言 , 并不需要對其進行提升 , 并且 , 如果 Rundll32.exe 進行了自動提升 , 則它通過命令行承載任意 DLL 的能力將會導致開發人員要求使用管理員權限 , 而自己卻未意識到 。
自 Windows Vista 測試版發布以來 , 最終用戶一直在要求 Windows 提供一種向自動提升列表中添加任意應用程序的方法 。 經常被提及的原因是:他們常用的某個第三方應用程序強制他們不斷單擊提升權限提示 , 而這已經成為他們日常工作的一部分 。 就像 Windows Vista 一樣 , Windows 7 并未提供這種功能 。 我們理解這種操作非常繁瑣 , 并且可能有這些應用程序無法在沒有管理權限的情況下運行的合理原因 , 但開發人員將會避免將其代碼修正為使用標準用戶權限 , 而這樣的風險太高 。 即使有關哪些應用程序進行自動提升的列表只能由管理員訪問 , 但開發人員只需更改其要求一次性提升的應用程序安裝程序 , 就可將其應用程序添加到列表中 。 作為替代 , 我們選擇進行投資來進行培訓并與應用程序開發人員密切合作 , 以確保其程序能夠以標準用戶身份正常工作 。
很多人發現 , 采用 PA 帳戶通過標準用戶權限運行的第三方軟件可以利用自動提升來獲取管理權限 。 例如 , 軟件可以使用 WriteProcessMemory API 將代碼注入資源管理器 , 并使用 CreateRemoteThread API 來執行該代碼 , 這種技術稱為 DLL 注入 。 由于代碼在資源管理器(一種 Windows 可執行文件)中執行 , 因此它可以利用自動提升的 COM 對象(比如“復制”/“移動”/“重命名”/“刪除”/“鏈接”對象)來修改系統注冊表項或目錄 , 并為軟件授予管理權限 。 如果是這樣 , 這些步驟將需要蓄意謀劃 , 而且并非無關緊要 , 因此 , 與將其軟件修正為使用標準用戶權限來運行相比較 , 我們不相信正當的開發人員會選擇進行這些步驟 。 事實上 , 我們建議任何應用程序開發人員不要依賴于系統中的提升行為 , 并且建議應用程序開發人員測試其軟件在標準用戶模式下運行的情況 。
接下來的發現是 , 惡意軟件可以使用同樣的技術獲取管理權限 。 同樣 , 情況確實如此 , 但正如我前面指出的 , 惡意軟件也可以通過提示的提升來危害系統 。 從惡意軟件的角度來看 , Windows 7 的默認模式并不比“始終通知”模式(“Vista 模式”)安全多少 , 并且 , 采用管理權限的惡意軟件在 Windows 7 的默認模式下運行時 , 將仍然會崩潰 。
結論:
總而言之 , UAC 是一組具有一個整體目標的技術:使用戶能夠以標準用戶身份運行 。 因為對 Windows 進行了更改 , 使標準用戶能夠執行以前需要管理權限的更多操作 , 再結合文件和注冊表虛擬化以及提示 , 從而共同實現了此目標 。 最終標準是:默認的Windows 7 UAC 模式通過減少提示使 PA 用戶的體驗更加流暢、允許用戶控制可以修改其系統的合法軟件 , 并仍然實現 UAC 的目標 , 即讓更多的軟件能夠在沒有管理權限的情況下運行 , 并繼續使軟件生態系統轉變為編寫能夠使用標準用戶權限工作的軟件 。
關于Win7操作系統的用戶帳戶控制功能就給大家敘述到這里了 , 還在懵圈的伙伴 , 可以將此文多看兩遍 , 相信大家就明白了!
【Win7操作系統用戶帳戶控制功能詳解收獲很多的】以上內容就是關于Win7操作系統用戶帳戶控制功能詳解收獲很多的的內容win7用戶帳戶控制,用戶帳戶控制uac的作用,電腦用戶帳戶控制 , 更新資訊請關注我們!

推薦閱讀