給予翻譯建議
 
其他人的建议:

progress indicator
無其他建議。
TechNet Magazine > 主页 > 所有期刊 > 2009 > TechNet Magazine 七月 2009 >  使用者帳戶控制: 置於 Windows 7 使用者帳戶控制
檢視內容: 並排檢視檢視內容: 並排檢視
社群成員可以對此機器翻譯的內容進行編輯。我們鼓勵您按一下與下面句子相關聯的「編輯」連結來改善翻譯。
User Account Control
Inside Windows 7 User Account Control
Mark Russinovich
 
At a Glance:
  • Standard user accounts
  • User account control

Standard user accounts provide for better security and lower total cost of ownership in both home and corporate environments. When users run with standard user rights instead of administrative rights, the security configuration of the system, including antivirus and firewall, is protected. This provides users a secure area that can protect their account and the rest of the system. For enterprise deployments, the policies set by desktop IT managers cannot be overridden, and on a shared family computer, different user accounts are protected from changes made by other accounts.
However, Windows has had a long history of users running with administrative rights. As a result, software has often been developed to run in administrative accounts and take dependencies, often unintentionally, on administrative rights. To both enable more software to run with standard user rights and to help developers write applications that run correctly with standard user rights, Windows Vista introduced User Account Control (UAC). UAC is a collection of technologies that include file system and registry virtualization, the Protected Administrator (PA) account, UAC elevation prompts, and Windows Integrity levels that support these goals. I've talked about these in detail in my conference presentations and TechNet Magazine UAC internals article.
Windows 7 carries forward UAC's goals with the underlying technologies relatively unchanged. However, it does introduce two new modes that UAC's PA account can operate with and an auto-elevation mechanism for some built-in Windows components. In this post, I'll cover the motivations behind UAC's technologies, revisit the relationship between UAC and security , describe the two new modes, and explain how exactly auto-elevation works. Note that the information in this post reflects the behavior of the Windows 7 release candidate, which is different in several ways from the beta.

UAC Technologies
The most basic element and direct benefit of UAC's technology is simply making Windows more standard-user friendly. The showcase example is the difference between the privilege requirements of setting the time zone on Windows XP and Windows Vista. On Windows XP, changing the time zone—actually, even looking at the time zone with the time/date control panel applet—requires administrative rights.
That's because Windows XP doesn't differentiate between changing the time, which is a security-sensitive system operation, from changing the time zone, which merely affects the way that time is displayed. In Windows Vista (and Windows 7), changing the time zone isn't an administrative operation and the time/date control panel applet separates administrative operations from the standard user operations. This change alone enables many enterprises to configure traveling users with standard user accounts, because users can adjust the time zone to reflect their current location. Windows 7 goes further, making things like refreshing the system's IP address, using Windows Update to install optional updates and drivers, changing the display DPI, and viewing the current firewall settings accessible to standard users.
File system and registry virtualization work behind the scenes to help many applications that inadvertently use administrative rights to run correctly without them. The most common unnecessary uses of administrative rights are the storage of application settings or user data in areas of the registry or file system that are for use by the system. Some legacy applications store their settings in the system-wide portion of the registry (HKEY_LOCAL_MACHINE\Software) instead of the per-user portion (HKEY_CURRENT_USER\Software), for example, and registry virtualization diverts attempts to write to the system location to one in HKEY_CURRENT_USER (HKCU) while preserving application compatibility.
The PA account was designed to encourage developers to write their applications to require only standard user rights while enabling as many applications that share state between administrative components and standard user components to continue working. By default, the first account on a Windows Vista or Windows 7 system, which was a full administrator account on previous versions of Windows, is a PA account. Any programs a PA user executes are run with standard-user rights unless the user explicitly elevates the application, which grants the application administrative rights. Elevation prompts are triggered by user activities such as installing applications and changing system settings. These elevation prompts are the most visible UAC technology, manifesting as a switch to a screen with an allow/cancel dialog and grayed snapshot of the desktop as the background.
Accounts created subsequent to the installation are standard user accounts by default that provide the ability to elevate via an "over the shoulder" prompt that asks for credentials of an administrative account that will be used to grant administrative rights. This facility enables a family member sharing a home computer or a more security-conscious user using a standard user account to run applications with administrative rights, provided they know the password to an administrative account, without having to manually switch to a different user logon session. Common examples of such applications include installers and parental control configuration.
When UAC is enabled, all user accounts—including administrative accounts—run with standard user rights. This means that application developers must consider the fact that their software won't have administrative rights by default. This should remind them to design their application to work with standard user rights. If the application or parts of its functionality require administrative rights, it can leverage the elevation mechanism to enable the user to unlock that functionality. Generally, application developers need to make only minor changes to their applications to work well with standard user rights. As the E7 blog post on UAC shows, UAC is successfully changing the way developers write software.
Elevation prompts also provide the benefit that they "notify" the user when software wants to make changes to the system, and it gives the user an opportunity to prevent it. For example, if a software package that the user doesn't trust or want to allow to modify the system asks for administrative rights, they can decline the prompt.

Elevations and Malware Security
The primary goal of UAC is to enable more users to run with standard user rights. However, one of UAC's technologies looks and smells like a security feature: the consent prompt. Many people believed that the fact that software has to ask the user to grant it administrative rights means that they can prevent malware from gaining administrative rights. Besides the visual implication that a prompt is a gateway to administrative rights for just the operation it describes, the switch to a different desktop for the elevation dialog and the use of the Windows Integrity Mechanism, including User Interface Privilege Isolation (UIPI), seem to reinforce that belief.
As we've stated since before the launch of Windows Vista, the primary purpose of elevation is not security, though, it's convenience: if users had to switch accounts to perform administrative operations, either by logging into or Fast User Switching to an administrative account, most users would switch once and not switch back. There would be no progress changing the environment that application developers design for. So what are the secure desktop and Windows Integrity Mechanism for?
The main reason for the switch to a different desktop for the prompt is that standard user software cannot "spoof" the elevation prompt, for example, by drawing on top of the publisher name on the dialog to fool a user into thinking that Microsoft or another software vendor is generating the prompt instead of them. The alternate desktop is called a "secure desktop," because it's owned by the system rather than the user, just like the desktop upon which the system displays the Windows logon dialog.
The use of another desktop also has an important application compatibility purpose: while built-in accessibility software, like the On Screen Keyboard, works well on a desktop that's running applications owned by different users, there is third-party software that does not. That software won't work properly when an elevation dialog, which is owned by the local system account, is displayed on the desktop owned by a user.
The Windows Integrity Mechanism and UIPI were designed to create a protective barrier around elevated applications. One of its original goals was to prevent software developers from taking shortcuts and leveraging already-elevated applications to accomplish administrative tasks. An application running with standard user rights cannot send synthetic mouse or keyboard inputs into an elevated application to make it do its bidding or inject code into an elevated application to perform administrative operations.
Windows Integrity Mechanism and UIPI were used in Windows Vista for Protected Mode Internet Explorer, which makes it more difficult for malware that infects a running instance of IE to modify user account settings, for example, to configure itself to start every time the user logs on. While it was an early design goal of Windows Vista to use elevations with the secure desktop, Windows Integrity Mechanism, and UIPI to create an impermeable barrier—called a security boundary—between software running with standard user rights and administrative rights, two reasons prevented that goal from being achieved, and it was subsequently dropped: usability and application compatibility.
Figure 1 Showing the executable fi le’s name.
First, consider the elevation dialog itself. It displays the name and publisher of the primary executable that will be granted administrative rights. Unfortunately, while greater numbers of software publishers are digitally signing their code, there are those that aren't, and there are many older applications that aren't signed. For software that isn't signed, the elevation dialog simply shows the executable's file name, which makes it possible for malware already running in a users account and that's watching for an elevation of an unsigned Setup.exe application installer, for example, to replace the executable with a malicious Setup.exe without the user being able to tell (see Figure 1).
Second, the dialog doesn't tell the user what DLLs the executable will load once it starts. If the executable resides in a directory under the user's control, malware running with the user's standard rights can replace any associated DLLs in the location that the software will use. Alternatively, malware could use side-by-side functionality to cause the executable to load malicious versions of application or system DLLs. And unless a user vigilantly clicks the details button and carefully looks at the file path listed for the elevating executable, malware can copy the executable to a similarly named location, for example, \ProgramFiles\Vendor\Application.exe (note the missing space in what should be "Program Files"), where it could control what DLLs the application loads. In Figure 2, I've copied a component of Microsoft Network Monitor to the user-created C:\ProgramFiles directory that's controllable by the user and launched it.
Figure 2 Launched copy of Microsoft Network Monitor component.
Finally, for application compatibility, elevated applications share substantial state with the standard user environment that a malicious application could use to influence the behavior of an elevated application. The clearest example of this is the user's registry profile, HKEY_CURRENT_USER (HKCU). That is shared because users expect settings and extensions they register as a standard user to work in elevated applications. Malware could use shell extensions registered in HKCU to load into elevated applications that use any of the shell browsing dialogs, like File Open and File Save. Other kinds of state are also shared, most notably the Base Named Object namespace, where applications create synchronization and shared memory objects. Malware could take advantage of that sharing to hijack a shared memory object used by an elevated application, for instance, to compromise the application and then the system.
As for the Windows Integrity Mechanism, its effectiveness as a barrier is limited by the elevation issues I've mentioned, but it also has limitations caused by application compatibility. For one, UIPI doesn't prevent standard user applications from drawing on the desktop, something that could be used to trick the user into interacting with elevated applications in a way that grants malware administrative rights. Windows Integrity Mechanism also doesn't flow across the network. A standard user application running in a PA account will have access to system resources on a remote system on which that PA account has administrative rights. Addressing these limitations has major application compatibility ramifications. That said, that we are continually looking at ways to improve system security, for instance, improving Protected Mode IE, while at the same time addressing application compatibility issues and working closely with software developers.
So, how much malware protection do you get when you run in a Windows Vista PA account with UAC enabled? First, remember that for any of this to matter, malware has to get onto the system and start executing in the first place. Windows has many defense-in-depth features, including Data Execution Prevention (DEP), Address Space Load Randomization (ASLR), Protected Mode IE, the IE 8 SmartScreen Filter, and Windows Defender that help prevent malware from getting on the system and running.
As for the case where malware somehow does manage to get on a system, because malware authors (like legitimate developers) have assumed users run with administrative rights, most malware will not function correctly. That alone could be considered a security benefit. However, malware that's gotten on a system and that's designed to exploit the opportunities might be able to gain administrative rights the first time the user elevates—but the malware doesn't even need to wait for a "real" elevation because it can precipitate one that would fool even the most security conscious users. I've demonstrated publicly how malware can hijack the elevation process in my UAC Internals and Windows Security Boundaries presentations (the demo is at minute 1:03 in the security boundaries talk). Remember, though, if malware does start running, it can accomplish most of the things that malware wants to do with just standard user rights, including configuring itself to run every time the user logs on, stealing or deleting all the user's data, or even becoming part of a botnet.

What's Different in Windows 7
I mentioned some of the operations in Windows 7 that can now be performed by standard users, but as the E7 blog post on UAC explains, we also recognized that we could make the Windows experience smoother without sacrificing UAC's goals. Many users complained about the fact that Windows Vista itself frequently asks for administrative rights when they perform common system management operations. It's in our best interest, because it's in the interest of our customers, to make Windows work well for standard user environments. However, elevation prompts don't educate or encourage us to do so, but they do force users to click a second time through a dialog that the vast majority of users don't read. Windows 7, therefore, set out to minimize those prompts from the default Windows experience and enable users that run as administrators to control their prompting experience.
To do that, we further refactored the system such that someone with standard user rights can execute more tasks, and we reduced the number of prompts in several multi-prompt scenarios (for example, installing an ActiveX control in IE). Windows 7 also introduces two new UAC operating modes that are selectable in a new UAC configuration dialog (see Figure 3). You can open the dialog by going to Control Panel, clicking User Accounts, clicking User Accounts, and then clicking Change User Account Control Settings. (You can also get to it by clicking on the Change When Notifications Appear link on an elevation prompt or by going through the Action Center.)
Figure 3 Two new UAC operating modes that are selectable in a new UAC configuration dialog.
The default setting, shown in Figure 3, is one of the new levels. Unlike Always Notify, which is the selection at the top of the slider and is identical to the default mode in Windows Vista, the Windows 7 default prompts the user only when a non-Windows executable asks for elevation; the behavior for non-Windows elevations is the same as it was for Windows Vista.
The next slider position down is the second new setting and has the same label except with "(do not dim my desktop)" appended to it. The only difference between that and the default mode is that prompts happen on the user's desktop rather than on the secure desktop. The upside of that is that the user can interact with the desktop while a prompt is active, but as I mentioned earlier, the risk is that third-party accessibility software might not work correctly on the prompt dialog.
Finally, the bottom slider position turns off UAC technologies altogether, so that all software running in a PA account runs with full administrative rights, file system and registry virtualization are disabled, and Protected Mode IE is disabled. While there are no prompts at this setting, the loss of Protected Mode IE is a significant disadvantage of this mode.

Auto-Elevation
The reason that elevation of (most) Windows executables in the two middle settings doesn't result in a prompt is that the system "auto elevates" Windows executables. First, what does Windows define as a Windows executable in this context? The answer depends on several factors, but two things must hold: it must be digitally signed by the Windows publisher, which is the certificate used to sign all code included with Windows (it's not sufficient to be signed by Microsoft, so Microsoft software that's not shipped in Windows isn't included); and it must be located in one of a handful of "secure" directories. A secure directory is one that standard users can't modify and they include %SystemRoot%\System32 (e.g., \Windows\System32) and most of its subdirectories, %SystemRoot%\Ehome, as well as a handful of directories under %ProgramFiles% that include Windows Defender and Windows Journal.
Also, depending on whether the executable is a normal .exe, Mmc.exe, or a COM object, auto-elevation has additional rules. Windows executables (as just defined) of the .exe variety auto-elevate if they specify the autoElevate property in their manifest, which is also where applications indicate to UAC that they want administrative rights. Here's the Sysinternals Sigcheck utility dumping the manifest for Task Manager (Taskmgr.exe) with the command "sigcheck –m %systemroot%\system32\taskmgr.exe", which shows that Task Manager is opted in for auto-elevation, as shown in Figure 4 .
Figure 4 The autoElevate Property
An easy way to find auto-elevate executables in a directory tree is to use the Sysinternals Strings utility with a command like this:
strings –s *.exe | findstr /i autoelevate
There is also a hardcoded list of Windows executables that get the auto-elevate treatment. These Windows executables also ship external to Windows 7 and so must be able to run on down-level systems where the presence of the autoexecute property would result in an error. The list includes Migwiz.exe, the migration wizard, Pkgmgr.exe, the package manager, and Spinstall.exe, the Service Pack installer.
The Microsoft Management Console, Mmc.exe, gets special treatment since it hosts many of the system management snap-ins, which are implemented as DLLs. Mmc.exe launches with a command line that specifies a .MSC file that lists the snap-ins MMC is to load. When Windows sees Mmc.exe ask for administrative rights, which it does when launched from a PA account, it validates that Mmc.exe is a Windows executable and then checks the .MSC. To be eligible for auto-elevation, the .MSC file must satisfy the Windows executable criteria (signed by Windows in a secure location) and it must be listed on an internal list of auto-elevate .MSCs. That list includes virtually all the .MSC files shipped with Windows.
Finally, COM objects can specify the need for administrative rights with a registry value in their registry key by creating a subkey named Elevation with a value named Enabled that is set to 1. Figure 5 shows the registry key for the shell's Copy/Move/Rename/Delete/Link Object that Explorer uses when a user performs a file system operation on a location their account doesn't have permissions for.
Figure 5 Shell Registry Key
For a COM object to be auto-elevated, it must also be a Windows executable and it must have been instantiated by a Windows executable. (The instantiating executable doesn't need to be marked for auto-elevation, though.) When you use Explorer to create a directory in the %ProgramFiles% directory from a PA account, for instance, the operation will auto-elevate because the COM object requests elevation, the object's DLL is a Windows executable, and Explorer is a Windows executable.

Auto-Elevation and UAC's Goals
So what's behind all the special auto-elevation rules? Choosing what to auto-elevate and what not to was guided by the question, "Can an application developer inadvertently or trivially depend on administrative rights by leveraging auto-elevate?" Since Cmd.exe can be used to execute batch scripts via command-line arguments and average users have no need to run command prompts elevated (most don't even know what a command prompt is), it was not manifested for auto-elevation. Similarly, Rundll32.exe, the executable that hosts control panel plug-ins, doesn't auto-elevate in the final release of Windows 7 because its elevation isn't required for any common management tasks, and if it auto-elevated, its ability to host arbitrary DLLs via its command-line could cause a developer to require administrator rights without realizing it.
End users have been asking for Windows to provide a way to add arbitrary applications to the auto-elevate list since the Windows Vista beta. The commonly cited reason is that some third-party application they frequently use forces them to constantly click through an elevation prompt as part of their daily routine. Windows 7, just like Windows Vista, doesn't provide such a capability. We understand the aggravation, and there might be a legitimate reason that those applications can't run without administrative rights, but the risk is too high that developers will avoid fixing their code to work with standard user rights. Even if the list of what applications get auto-elevated was only accessible by administrators, developers might simply change their application setup program, which requires a one-time elevation, to add their application to the list. We've instead chosen to invest in educating and working closely with application developers to ensure their programs work correctly as a standard user.
Several people have observed that it's possible for third-party software running in a PA account with standard user rights to take advantage of auto-elevation to gain administrative rights. For example, the software can use the WriteProcessMemory API to inject code into Explorer and the CreateRemoteThread API to execute that code, a technique called DLL injection. Since the code is executing in Explorer, which is a Windows executable, it can leverage the COM objects that auto-elevate, like the Copy/Move/Rename/Delete/Link Object, to modify system registry keys or directories and give the software administrative rights. While true, these steps require deliberate intent, aren't trivial, and therefore are not something we believe legitimate developers would opt for versus fixing their software to run with standard user rights. In fact, we recommend against any application developer taking a dependency on the elevation behavior in the system and that application developers test their software running in standard user mode.
The follow-up observation is that malware could gain administrative rights using the same techniques. Again, this is true, but as I pointed out earlier, malware can compromise the system via prompted elevations as well. From the perspective of malware, Windows 7's default mode is no more or less secure than the Always Notify mode ("Vista mode"), and malware that assumes administrative rights will still break when run in Windows 7's default mode.

Conclusion
To summarize, UAC is a set of technologies that has one overall goal: to make it possible for users to run as standard users. The combination of changes to Windows that enable standard users to perform more operations that previously required administrative rights, file and registry virtualization, and prompts all work together to realize this goal. The bottom line is that the default Windows 7 UAC mode makes a PA user’s experience smoother by reducing prompts, allows them to control what legitimate software can modify their system, and still accomplishes UAC’s goals of enabling more software to run without administrative rights and continuing to shift the software ecosystem to write software that works with standard user rights.

Mark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division.

使用者帳戶控制
內部的 Windows 7 使用者帳戶控制
Mark Russinovich
 
一眼:
  • 標準使用者帳戶
  • 使用者帳戶控制

標準使用者帳戶提供較佳的安全性與較低家庭和公司環境中的擁有權總成本。 當使用者執行以標準使用者權限,而非系統管理員權限時,受到保護的系統,包括防毒及防火牆,安全性設定。 這會提供使用者可以保護其帳戶和系統的其他一個安全區域。 企業的部署桌面的 IT 管理員所設定的原則無法覆寫,並在共用家庭電腦上不同的使用者帳戶會防止其他帳戶所做的變更。
但是,Windows 具有長歷程記錄的使用者具有系統管理權限執行。 結果軟體有通常被開發,以在系統管理帳戶下執行,並在系統管理員權限,通常就無意攜帶相依性。 同時啟用更多的軟體,以標準使用者權限來執行而且為了開發人員撰寫應用程式,以標準使用者權限正確執行 Windows Vista 使用者帳戶控制 (UAC)。 UAC 是包含檔案系統和登錄虛擬化、 受保護系統管理員 (PA) 帳戶、 UAC 的提高權限提示與支援這些目標的 Windows 整合層級的技術的集合。 我已經討論有關這些詳細資料中我 會議簡報 TechNet 雜誌 UAC 內部 發行項。
執行 Windows 7 會向前 UAC 的目標與基礎的技術相當不變。 但是,它不會造成兩種新模式,UAC 的 PA 帳戶可以使用作業和某些內建的 Windows 元件的自動提高權限機制。 在此後,我會討論 motivations 背後 UAC 的技術 重新修定關係 UAC 和安全性 描述在兩個新模式並解釋如何完全自動提高權限的運作方式。 請注意此後的資訊會反映不同幾種方式從測試 Windows 7 發行候選的行為。

UAC 的技術
直接優點 UAC 的技術與最基本的項目只讓 Windows 更多的標準使用者易記。 展示範例是差異在 Windows XP 和 Windows Vista 上設定的時區的權限需求。 在 Windows XP,變更時區,實際,甚至查看時區的時間/日期控制台小程式,需要系統管理權限。
這是因為 Windows XP 不區分從變更時區,時間的方式會顯示哪些只是影響變更時間是敏感的安全性系統的作業。 在 Windows Vista (和 Windows 7) 變更時區沒有系統管理作業,並時間/日期控制台小程式隔開從標準使用者作業的管理作業。 這項變更只可讓許多企業以標準使用者的帳戶設定傳輸的使用者,因為使用者可以調整以反映目前的位置的時區。 Windows 7 進一步,會使之類的重新整理系統的 IP 位址、 使用 Windows Update 安裝選用的更新及驅動程式、 變更顯示 DPI,及檢視標準使用者存取目前的防火牆設定。
檔案系統和登錄模擬工作在幕後幫助許多應用程式,不小心讓系統管理員權限沒有正確執行。 最常見的不必要使用系統管理權限的是應用程式設定] 或 [由系統所使用的登錄或檔案系統的區域中的使用者資料的儲存體。 某些舊版的應用程式儲存其設定的登錄 (HKEY_LOCAL_MACHINE\Software) 全系統的部份每位使用者部分 (HKEY_CURRENT_USER\Software,) 而不是,就例如並登錄虛擬化 diverts 嘗試寫入到一個中 HKEY_CURRENT_USER (HKCU),系統位置時保留應用程式相容性。
PA 帳戶被設計來鼓勵開發人員撰寫應用程式時啟用共用系統管理的元件和繼續使用標準使用者元件之間的狀態的多個應用程式需要只標準使用者權限。 預設情況下,Windows Vista 或 Windows 7 系統,是 Windows 的舊版,以完整系統管理員帳戶上第一個帳戶是 Windows 的 PA 帳戶。 PA 使用者執行任何程式正在執行以標準使用者權限,除非使用者明確 elevates 應用程式會授與應用程式系統管理權限。 提示提高權限是由使用者活動,例如安裝應用程式,和變更系統設定觸發。 這些提高權限提示是 manifesting 為切換至使用允許/取消對話方塊和灰色的快照集作為背景桌面的螢幕,最明顯 UAC 技術。
安裝之後建立的帳戶是讓能夠提高權限的 「 透過肩部 」 提示,要求會用來授與系統管理權限的系統管理帳戶認證透過標準使用者帳戶依預設值。 此功能可讓家庭成員共用家用電腦或較注重安全性的使用者提供他們知道要管理的帳號的密碼而不必手動切換到不同的使用者登入工作階段,擁有系統管理權限,執行應用程式使用標準使用者帳戶。 這類應用程式的常見範例包括,安裝程式] 及 [家長監護設定。
啟用 UAC 時,所有的使用者帳戶 (包括系統管理帳戶,以標準使用者權限執行。 這表示應用程式開發人員必須考慮他們的軟體不具有系統管理權限依預設值。 這應該提醒他們設計的應用程式使用標準使用者權限。 如果它的功能部份的應用程式需要系統管理權限,它可以使用提高權限的機制讓使用者解除鎖定該功能。 通常,應用程式開發人員需要變更只次要也使用標準使用者權限的應用程式。 在 UAC E7 部落格張貼 顯示 UAC 成功地變更,開發人員撰寫軟體的方法。
提高權限提示也提供的好處他們 「 通知 」 使用者軟體想對系統,變更,並讓使用者有機會,所以。 就例如如果軟體套件,是使用者不信任或想要修改系統允許要求的系統管理員權限,它們可以拒絕提示。

提升權限和惡意程式碼安全性
UAC 的主要目標是要讓多個使用者以標準使用者權限來執行。 UAC 的技術之一,然而,外觀和聞像一項安全性功能: 同意提示。 許多人相信軟體對要求使用者授與系統管理權限的事實表示它們可以防止惡意程式碼取得系統管理權限。 除了視覺化的含意,提示是一閘道,它說明了在操作系統管理權限以,切換到不同的桌面,Windows 完整性機制包括使用者介面權限隔離 (UIPI),使用 [提高權限] 對話方塊,看起來強化的信念。
我們已 指出因為之前啟動的 Windows Vista,提高權限的主要目的不是安全性,但是,很方便: 如果使用者必須切換帳戶來執行藉由登入] 或 [快速使用者切換管理的帳號的管理作業便會一次切換大部分的使用者,並不切換回。 會有變更,應用程式開發人員設計的環境沒有進行。 因此什麼是安全的桌面及 Windows 完整性機制的?
切換到不同的桌面,提示主要原因是標準使用者軟體無法 「 偽造 」 [提高權限] 提示,就例如藉由繪製在最上面的 [到這個笨老頭到 Microsoft 或其他的軟體廠商會產生而不是個提示的思考模式的使用者] 對話方塊上發行者名稱。 稱為 「 安全桌面",替代的桌面,因為它所擁有的系統,而非使用者,就像在桌面上,在其系統會顯示 [Windows 登入] 對話方塊。
另一個桌面的使用也有一個重要的應用程式相容性用途: 在螢幕鍵盤,像的內建的協助工具軟體時也會在桌面上執行的應用程式的運作方式所擁有不同的使用者沒有協力廠商軟體,並不會。 軟體不會運作正常時的提高權限] 對話方塊由本機系統帳戶,所擁有的被顯示在桌面上由使用者所擁有。
UIPI 與 Windows 完整性機制被設計來建立保護性的屏障周圍提高權限的應用程式。 其原始的目標之一是防止軟體開發人員,取得快速鍵和運用特殊權限已經-提高應用程式來完成系統管理工作。 以標準使用者權限執行應用程式無法傳送合成的滑鼠或鍵盤輸入到提高權限應用程式,讓它執行其二手或程式碼注入提高應用程式來執行管理作業。
Windows 完整性機制和 UIPI 已用於 Windows Vista 中受保護模式 Internet Explorer,讓它更難感染正在執行的 IE,例如修改使用者帳戶設定值,以設定本身開始每次使用者登入時執行個體的惡意軟體。 時的 Windows Vista 的早期設計目標與安全桌面、 Windows 整合機制及 UIPI 使用提升權限,來建立一個 impermeable 障礙 — 稱為安全性界限,之間以標準使用者權限和系統管理的權限執行的軟體兩個原因禁止該目標所達成和中斷之後: 可用性和應用程式的相容性。
[圖 1 顯示 可執行檔 fi (’s 名稱。
首先,考慮本身 [提高權限] 對話方塊。 它會顯示名稱和主要可執行檔,將會被授與系統管理權限的發行者。 不幸的是,雖然軟體發行者的較大的數字數位簽署其程式碼,有那些不,且有許多較舊的應用程式,不帶正負號。 不帶正負號的軟體 [提高權限] 對話方塊只會顯示可執行檔的檔案名稱,這可讓惡意程式碼正在執行使用者帳戶,監督的不帶正負號的 Setup.exe 應用程式安裝的是提高權限,就例如取代惡意的 Setup.exe 中的可執行檔,而不需使用者能夠告訴 (請參閱 [ 圖 1 ])。
第二個,[] 對話方塊不會告訴使用者一旦啟動之後,可執行檔會載入哪些 DLL。 如果可執行檔所在目錄,以在使用者控制下,惡意程式碼執行以使用者的標準權限可以取代任何相關聯的 DLL 在軟體會使用的位置中。 或者,惡意程式碼可以使用-並存功能會造成以載入惡意的版本,應用程式或系統 DLL 的可執行檔。 並將除非使用者 vigilantly 按下 [詳細資料] 按鈕,並且仔細查看所列的提升的可執行檔的檔案路徑,惡意程式碼可以複製可執行檔到一個類似命名位置,就例如 \ProgramFiles\Vendor\Application.exe (注意何者應該 [程式檔案] 遺失空間),它可以控制哪些 DLL 應用程式的負載。 圖 2 ,我已複製到使用者建立 C:\ProgramFiles 目錄可由使用者控制並啟動它 Microsoft 網路監視器 」 的元件。
[圖 2 Launched 複本的 Microsoft 網路監視器的元件。
最後,至於應用程式的相容性更高的應用程式會路上與標準使用者環境,惡意的應用程式可以用來提高應用程式的行為會影響大量的狀態。 這在 clearest 範例就是使用者的登錄設定檔,HKEY_CURRENT_USER (HKCU)。 因為使用者預期設定和延伸它們登錄在提高權限的應用程式中使用標準使用者身分共用的。 惡意程式碼可以使用在 HKCU 中註冊的殼層延伸來載入到提高權限的應用程式並使用任何的殼層瀏覽開啟舊檔] 和 [儲存檔案的對話方塊。 其他種類的狀態也會共用,命名最值得注意的是基底命名的物件空間,應用程式建立同步處理和共用的記憶體物件的位置。 惡意程式碼可以利用該共用劫持一個執行個體使用的提高權限的應用程式的共用的記憶體物件,而危及應用程式,然後系統。
至於 Windows 整合性機制中,障礙為其效果會受到我已提到,提高權限問題,但也有由應用程式相容性所造成的限制。 一個,UIPI 並不會防止標準使用者應用程式,從繪圖可以用來誘騙使用者與提高權限的應用程式,系統管理員權限授與惡意程式碼互動的項目在桌面上。 Windows 完整性機制也不會透過網路傳送。 PA 帳戶中執行的標準使用者應用程式會對在其該 PA 帳戶擁有系統管理權限的遠端系統上存取系統資源。 解決這些限制有主要的應用程式相容性細節。 話雖如此,我們會持續尋找在改善系統的安全性方法對於執行個體改善受保護模式 IE 的時同時處理應用程式相容性問題,並密切使用軟體開發人員。
因此,多少惡意程式防護您取得? 當您執行 Windows Vista PA 帳戶中有啟用 UAC 第一次,請記住對於任何此重要,惡意程式碼具有取得到系統,並開始執行的。 Windows 擁有許多的深度防禦功能包括資料執行防止 (DEP)]、 [地址空間載入隨機 (ASLR)]、 [受保護模式 IE]、 [IE] 8 SmartScreen 篩選器,] 和 [Windows Defender,幫助防止惡意軟體在系統上取得,並執行。
至於讓惡意程式碼有並管理以取得系統的大小寫,因為惡意軟體作者 (像是合法的開發人員) 必須假設使用者執行系統管理權限,大多數的惡意程式碼會正常運作。 單獨可能被視為安全性好處。 但是,惡意程式碼,在系統上的內部和,是設計來利用此機會可能可以取得系統管理權限第一次使用者 elevates — 但惡意程式碼甚至不需要等待 「 真正 」 的提高權限,因為它可以 precipitate 一個會將這個笨老頭甚至最安全意識使用者。 我已公開示範如何惡意程式碼可以劫持提高權限處理程序中的我 UAC 內部 Windows 安全性界限 簡報 (示範位於分鐘 1: 03 安全性界限與交談中)。 記住雖然如果惡意程式碼不會開始執行,就可以完成大部分的項目惡意軟體想要做只是標準使用者權限包括設定每次使用者登入時執行本身、 竊取或刪除使用者的所有資料,或甚至成為一個 botnet 的一部份。

有什麼不同 Windows 7
我提到的部分作業,現在可以執行標準的使用者的 Windows 7] 中,但為 E7 部落格張貼在 UAC 說明,我們也會識別我們可以讓 Windows 經驗變得更平穩而無需 UAC 的目標。 許多使用者 complained 本身的 Windows Vista 經常要求的系統管理權限執行一般的系統管理作業時,有關。 那中我們最感興趣,因為它是我們的客戶,讓 Windows 適用於標準的使用者環境中。 但是,提高權限提示不教育或鼓勵我們要執行這項操作,但它們執行強制使用者按一下第二個透過一個對話方塊,大多數的使用者不讀取時間。 Windows 7,因此,將出降至最低預設的 Windows 經驗的提示,並讓控制其提示的經驗的系統管理員身分執行的使用者。
要執行這項操作,我們進一步重構系統,以標準使用者權限的人可以執行更多的工作,並且我們降低提示在數個 multi-prompt 案例中 (例如,在 IE 中安裝 ActiveX 控制項) 的數目。 Windows 7 也介紹兩個新 UAC 作業模式可在新的 UAC 設定] 對話方塊中選取的 (請參閱 [ 圖 3 ])。 您可以前往 [控制台]、 [使用者帳戶]、 [使用者帳戶,] 及 [變更使用者帳戶控制設定],以開啟 [] 對話方塊。 (您也可以取得它藉由按一下變更時通知顯示連結已提高權限提示字元上或透過 「 動作 」)。
[圖 3 兩個新 UAC 作業模式是可選取一個新 UAC 設定] 對話方塊。
預設顯示於 [ 圖 3 ,是其中一個新的層級。 不像自動通知,這是選取範圍頂端的滑桿,等於預設的模式在 Windows Vista,Windows 7 預設值為非 Windows 可執行檔要求提高權限時,才會提示使用者 ; 非 Windows 提升權限的行為是相同的 Windows Vista 的]。
下一個滑桿位置向下的是第二個新設定,並已附加到它的除了與 「 (執行不暗我的桌面) 」 相同的標籤。 以及預設的模式,唯一差別在於使用者的桌面,而非安全桌面提示會發生。 在的優點是使用者可以與桌面互動時提示,是使用中,但如前所述,風險是第三方廠商的協助工具軟體可能無法正確地在 [提示] 對話方塊。
最後,下方的滑桿位置關閉 UAC 技術位,所以 PA 帳戶中執行的所有軟體會以完整系統管理權限都執行、 停用檔案系統和登錄虛擬化和受保護模式 IE 已停用。 時在此設定沒有提示這個模式的重大缺點會受保護模式 IE 的遺失。

自動升級
權限提高 (大部分) 的 Windows 可執行檔在兩個中間設定並不會導致提示,原因是,系統自動 elevates"Windows 執行檔。 第一次,什麼並 Windows 定義為在此內容中的一個 Windows 可執行檔? 答案取決於幾個因素,但必須保留兩件事: 它必須數位簽章由是用來簽署隨附的 Windows (它是不進行簽章 Microsoft,所以不在 Windows 中的出貨的 Microsoft 軟體不包含足夠) ; 所有的程式碼的憑證的 [Windows] 發行者,而它必須放置中的 「 安全 」 目錄的其中一個。 安全目錄便是一個標準的使用者無法修改,而它們包含 %SystemRoot%\System32 (例如,\Windows\System32) 和它的子目錄,%SystemRoot%\Ehome,以及的目錄下 %ProgramFiles %,包括 Windows Defender] 和 [Windows 筆記本的大部分。
而且,根據可執行檔是否正常的.exe、 Mmc.exe 或 COM 物件,自動提高權限有其他規則。 Windows 執行檔 (為只定義),.exe 各種不同的自動-提升如果它們指定 autoElevate 屬性,它們也是在應用程式指示 UAC 他們想要的系統管理權限的資訊清單中。 以下是 [Sysinternals Sigcheck 傾印資訊清單的工作管理員 (Taskmgr.exe) 與 [命令] sigcheck –m %systemroot%\system32\taskmgr.exe 」,顯示 [工作管理員中選擇的自動上下仰角] 中所示的公用程式 [圖 4 .
[圖 4 的 autoElevate 屬性
輕鬆地尋找自動-提升可執行檔目錄中樹狀目錄是使用 Sysinternals 字串公用程式與命令如下:
strings –s *.exe | findstr /i autoelevate
還有硬式編碼清單,讓 Windows 可執行檔的自動提高處理。 這些 Windows 可執行檔也出貨的外部,Windows 7,且因此必須能夠在下層的系統上執行其中的 autoexecute 屬性存在會導致錯誤。 此清單包括 Migwiz.exe、 移轉精靈、 Pkgmgr.exe,封裝管理員及 Spinstall.exe,Service Pack 安裝程式。
Microsoft 管理主控台 Mmc.exe,取得特殊的處理,因為它在裝載許多系統管理嵌入式管理單元,為 DLL 會實作。 Mmc.exe 啟動以命令列指定.MSC 檔案列出 MMC 嵌入式管理單元正在載入。 當 Windows 看到 Mmc.exe 尋求它會從一個的 PA 帳戶啟動時的系統管理權限時它將會驗證 Mmc.exe 是 Windows 可執行檔,然後檢查 [.MSC。 要能夠自動提高權限,.MSC 檔案必須符合 Windows 可執行檔準則 (在安全的位置的 Windows 帶正負號),且它必須列在內部清單的自動提高.MSCs。 該清單包含了 Windows 所隨附的幾乎所有.MSC 檔案。
最後,COM 物件可以指定需要系統管理權限的登錄值的登錄機碼中建立子機碼值名稱設定為 1 的啟用以命名高度。 [圖 5 ] 顯示登錄機碼殼層的複製/移動/重新命名/刪除/連結物件總管時使用者執行位置上的檔案系統作業所使用的帳戶沒有權限。
[圖 5 Shell 登錄機碼
如為特殊權限自動-提高,COM 物件也必須是一個可執行檔的 Windows,然後它必須具現化一個 Windows 可執行檔]。 (不過要標記成自動上下仰角並不會需要 instantiating 的可執行檔)。 使用檔案總管從 PA 帳號 %ProgramFiles %目錄中建立目錄時對於執行個體作業會自動為提升因為 COM 物件要求提高權限、 物件的 DLL 是一個的 Windows 執行檔,總管是 Windows 可執行檔。

自動提高權限和 UAC 的目標
因此什麼特殊自動提高的權限的所有規則背後? 選擇自動提高權限以及內容不到已指引由的問題 」 應用程式開發人員可以在不小心或都依賴系統管理權限,利用自動提高? 」 因為 Cmd.exe 可以用來執行批次指令碼,透過命令列引數,而平均的使用者可以不需要執行提高權限的命令提示字元 (甚至不知道大部分是何種命令提示字元),它不功能性自動提高權限。 同樣地,Rundll32.exe,主機控制面板外掛程式可執行檔並不會自動-提升在最終版本的 Windows 7 因為其提高權限並不需要任何常見的管理工作,而且如果它特殊權限自動-提高,能夠裝載透過其命令列的任意 DLL 可能會導致需要系統管理員權限,而不自知,開發人員。
使用者已被要求提供方法來新增任意應用程式,Windows 將自動-提高清單後,Windows Vista Beta 版。 通常上述的原因是常式的它們經常使用某些協力廠商應用程式強制,不斷地按一下 [透過的提高權限提示為其每日的一部分。 就像 Windows Vista,[Windows] 7 並不提供這類功能。 我們了解 aggravation,和可能有合法的原因,這些應用程式無法執行沒有系統管理的權限,],但在風險是太高的開發人員會避免修正使用 [標準使用者權限程式碼]。 即使有哪些應用程式的清單取得自動資源被提高後只可由系統管理員存取,開發人員可能只需要變更需要在一次的上下仰角若要新增至清單中其應用程式的應用程式安裝程式。 我們而選擇投資在教育,及使用密切與應用程式開發人員,以確保其程式正常運作,以標準使用者身分。
許多人有觀察到的可能 PA 帳戶以利用自動的提高權限來取得系統管理權限的標準使用者權限執行的第三方廠商軟體。 該軟體可以用,就說, WriteProcessMemory API 來插入檔案總管中的程式碼, CreateRemoteThread 執行該程式碼一項技巧的 API 呼叫 DLL 資料隱碼。 因為程式碼在 [檔案總管是 Windows 可執行檔中執行它可以使用 COM 物件的自動提高權限,要修改系統登錄機碼或目錄,並提供軟體系統管理權限的 [複製/移動/重新命名/刪除/連線] 物件。 時則為 True,這些步驟需要故意的目的,不是一般,因此是不相信合法的開發人員會選擇與修正軟體能以標準使用者權限執行的項目。 在就其實我們建議您針對任何應用程式開發人員,取得相依性提高權限行為在系統和應用程式開發人員測試他們在標準使用者模式下執行的軟體。
待處理的觀察是,惡意程式碼可以取得系統管理權限使用相同的技術。 一次,這是,則為 True,但如我先前指出的惡意程式碼可能會危害系統透過也 prompted 提升權限。 從惡意程式碼的觀點來看,Windows 7 的預設模式不比自動通知模式 (Vista 模式) 更多或更少安全並執行於 Windows 7 的預設模式時,仍然會中斷惡意程式碼假設系統管理員權限。

結論
合併彙算,UAC 是技術的一個整體的目標一組:,讓使用者以標準使用者身分執行。 組合,先前需要系統管理權限、 檔案和登錄虛擬化,讓標準使用者執行的作業的 Windows 變更,並提示一起,以實現此目標的所有工作。 最是預設的 Windows 7 UAC 模式會藉由減少提示 PA 使用者 ’s 經驗變得更平穩、 讓他們來控制哪些合法軟體可以修改他們的系統,而且仍然完成啟用更多軟體沒有系統管理權限執行的軟體生態系統轉移,可以使用標準使用者權限寫入軟體繼續 UAC ’s 目標。

標記 Russinovich 在 Microsoft 平台和服務部門中的一個技術夥伴。

Page view tracker