Sugerir tradução
 
Outras sugestões:

progress indicator
Sem sugestões.
TechNet Magazine > Home > Todas as edições > 2009 > TechNet Magazine Julho 2009 >  Controle de conta de usuário: Inside Windows 7 ...
Exibir Conteúdo: Lado a LadoExibir Conteúdo: Lado a Lado
Este é um conteúdo traduzido por máquina que os membros da comunidade podem editar. Incentivamos você a melhorar a tradução clicando no link Editar associado a qualquer sentença abaixo.
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.

Controle de conta de usuário
Controle de conta de usuário do Windows 7 interna
Mark Russinovich
 
Visão geral:
  • Contas de usuário padrão
  • Controle de conta de usuário

Contas de usuário padrão proporcionam maior segurança e menor custo total de propriedade em ambientes domésticos e corporativos. Quando os usuários executam com direitos de usuário padrão em vez de direitos administrativos, a configuração de segurança do sistema, incluindo antivírus e firewall, é protegido. Isso fornece aos usuários uma área segura que pode proteger sua conta e o restante do sistema. Para implantações empresariais, as diretivas definidas por gerentes de TI da área de trabalho não podem ser substituídas e, em um computador compartilhado da família, diferentes contas de usuário são protegidas contra as alterações feitas por outras contas.
No entanto, o Windows tem tido um longo histórico de usuários que executam com direitos administrativos. Como resultado, software geralmente foi desenvolvido para executar em contas administrativas e assumir dependências, com freqüência, inadvertidamente, direitos administrativos. Para ambos permitem mais software executar com direitos de usuário padrão e para ajudar os desenvolvedores escrever aplicativos que são executados corretamente com direitos de usuário padrão, o Windows Vista introduziu UAC (controle de conta de usuário). UAC é uma coleção de tecnologias que incluem sistema de arquivos e virtualização de registro, a conta de administrador protegida (PA), solicitações de elevação do UAC e níveis de integridade do Windows que oferecem suporte a essas metas. Já falei sobre esses detalhes no meu apresentações de conferência e TechNet Magazine Aspectos internos do UAC artigo.
Windows 7 carrega consigo metas do UAC com as tecnologias subjacentes relativamente inalteradas. No entanto, ele introduzir dois novos modos PA conta do UAC pode operar com e um mecanismo automático elevação para alguns componentes do Windows internos. Esta postagem, que abordarei as motivações por trás tecnologias do UAC, Rever a relação entre segurança e UAC , descreva dois novos modos e explique como exatamente elevação automático funciona. Observe que as informações nesta postagem reflete o comportamento do Windows 7 versão RC, que é diferente de várias maneiras do beta.

Tecnologias do UAC
O elemento mais básico e direto benefícios da tecnologia do UAC é simplesmente fazendo Windows mais amigável de usuário padrão. O exemplo de demonstração é a diferença entre os requisitos de privilégio de definir o fuso horário no Windows XP e Windows Vista. No Windows XP, alterando o fuso horário — na verdade, até mesmo observar o fuso horário com o miniaplicativo Data/hora do painel de controle — requer direitos administrativos.
Isso ocorre porque o Windows XP não diferenciar alterando a hora, o que é uma operação sensível à segurança do sistema, alterem o fuso horário, que afeta apenas o maneira como o tempo é exibido. No Windows Vista (e no Windows 7), alterar o fuso horário não é uma operação administrativa e o miniaplicativo de painel de controle de data/hora separa as operações administrativas as operações de usuário padrão. Essa alteração somente permite que muitas empresas configurar usuários viajando com contas de usuário padrão, porque os usuários podem ajustar o fuso horário para refletir seu local atual. Windows 7 vai além disso, fazer coisas como atualizar endereço IP do sistema, usando o Windows Update para instalar as atualizações opcionais e drivers, alterar a exibição PPP e exibindo as configurações de firewall atuais podem ser acessados por usuários padrão.
Arquivo trabalho virtualização nos bastidores para ajudar a muitos aplicativos que usam inadvertidamente direitos administrativos para executar corretamente sem-los do Registro e sistema. Os usos mais comuns desnecessários de direitos administrativos são o armazenamento de dados do usuário em áreas do sistema do registro ou arquivo que são para uso pelo sistema ou as configurações do aplicativo. Alguns aplicativos herdados armazenam suas configurações na parte de todo o sistema de registro (HKEY_LOCAL_MACHINE\Software) em vez da parte por usuário (HKEY_CURRENT_USER\Software), por exemplo, e virtualização de registro diverts tentativas de gravação para o local de sistema para um em HKEY_CURRENT_USER (HKCU) enquanto preserva a compatibilidade de aplicativos.
A conta PA foi criada para encorajar os desenvolvedores escrevam seus aplicativos para exigir somente direitos de usuário padrão ao ativar como muitos aplicativos que compartilham o estado entre componentes administrativos e componentes de usuário padrão para continuar a trabalhar. Por padrão, a primeira conta em um sistema Windows Vista ou o Windows 7, que era uma conta de administrador completo em versões anteriores do Windows, é uma conta PA. Os programas que um usuário PA executa são executados com direitos de usuário padrão, a menos que o usuário explicitamente eleva o aplicativo, que concede os direitos administrativos do aplicativo. Solicitações de elevação são acionadas por atividades de usuário, como instalação de aplicativos e alterar as configurações do sistema. Esses prompts de elevação são a tecnologia mais visível do UAC, manifesting como uma opção para uma tela com um diálogo de permissões/Cancelar e cinza instantâneo da área de trabalho como plano de fundo.
Contas criadas subseqüentes para a instalação são contas de usuário padrão por padrão, que fornecem a capacidade de elevar por meio de um prompt "over the shoulder" que solicita credenciais de uma conta administrativa que será usado para conceder direitos administrativos. Esse recurso permite que um membro da família compartilhar um computador doméstico ou um usuário mais segurança-sensível à usando uma conta de usuário padrão para executar aplicativos com direitos administrativos, desde que eles souber a senha de uma conta de administrador, sem precisar alternar manualmente para uma sessão de logon de usuário diferente. Exemplos comuns de tais aplicativos incluem instaladores e configuração de controle dos pais.
Quando o UAC estiver habilitado, todas as contas de usuário — incluindo contas administrativas — executar com direitos de usuário padrão. Isso significa que os desenvolvedores de aplicativos devem considerar o fato de que seu software não possuem direitos administrativos por padrão. Isso deve lembrá-los para criar seu aplicativo para trabalhar com direitos de usuário padrão. Se o aplicativo ou partes de sua funcionalidade exigem direitos administrativos, ele pode aproveitar o mecanismo de elevação para permitir que o usuário desbloquear essa funcionalidade. Geralmente, os desenvolvedores de aplicativos precisam fazer apenas pequenas alterações seus aplicativos para funcionar bem com direitos de usuário padrão. Como o Postagem de blog E7 no UAC mostra, UAC com êxito é alterando a forma que os desenvolvedores escrevem software.
Solicitações de elevação também fornecem o benefício que eles "notificar" o usuário ao software deseja fazer alterações no sistema, e ele oferece o usuário a oportunidade de evitar que ele. Por exemplo, um pacote de software que o usuário não confia ou deseja permitir para modificar o sistema solicita direitos administrativos, eles podem recusar o prompt.

As elevações e segurança de Malware
O principal objetivo do UAC é permitir que mais usuários executar com direitos de usuário padrão. No entanto, uma das tecnologias do UAC é e smells como um recurso de segurança: prompt consentimento. Muitas pessoas acredita-se de que o fato de que o software deve perguntar ao usuário para conceder direitos administrativos significa que eles podem impedir que malware obtenham direitos administrativos. Além da implicação visual que um prompt é um gateway para direitos administrativos para apenas a operação que ele descreve, a opção para uma área de trabalho diferente para a caixa de diálogo elevação e o uso do mecanismo de integridade do Windows, incluindo UIPI (User Interface privilégio isolamento), parecer reforçar esse princípio.
Como nós já mencionado como antes do lançamento do Windows Vista, o objetivo principal de elevação não é segurança, no entanto, é conveniência: se os usuários tinham que alternar contas para executar operações administrativas, por log em ou troca rápida de usuário para uma conta administrativa, a maioria dos usuários seria alternar uma vez e não alterne de volta. Não deve haver nenhum progresso o ambiente que os desenvolvedores de aplicativos de design para a alteração. Assim, o que são a área de trabalho segura e mecanismo de integridade do Windows para?
O principal motivo para a opção para uma área de trabalho diferente para o prompt é que o software de usuário padrão não é possível "falsificar" prompt de elevação, por exemplo, desenhando na parte superior do nome do Editor na caixa de diálogo para enganar um usuário a pensar que o Microsoft ou de outro fornecedor de software está gerando o prompt em vez de. A área de trabalho alternativa é chamada "desktop seguro", porque ele é pertencentes o sistema em vez do usuário, assim como a área de trabalho no qual o sistema exibe a caixa de diálogo de logon da Windows.
O uso de outra área de trabalho também tem uma finalidade de compatibilidade de aplicativo importante: ao software internos de acessibilidade, como o teclado de tela no, funciona bem em uma área de trabalho que esteja executando aplicativos pertencentes a diferentes usuários, é existe um software de terceiros que não. Que o software não funcionará adequadamente quando uma caixa de diálogo de elevação, que pertence a conta do sistema local, é exibida na área de trabalho pertencente a um usuário.
O mecanismo de integridade do Windows e UIPI foram projetados para criar uma barreira protetora ao redor de aplicativos elevados. Um dos seus objetivos originais era impedir que os desenvolvedores de software de realizar atalhos e aproveitando aplicativos já elevados para realizar tarefas administrativas. Um aplicativo em execução com direitos de usuário padrão não pode enviar sintético mouse ou teclado entradas em um aplicativo elevado para torná-lo fazer sua aposta ou injetar código um aplicativo elevado para executar operações administrativas.
Mecanismo de integridade do Windows e UIPI eram usados no Windows Vista para Protected modo Internet Explorer, que torna mais difícil para o malware infecta uma instância em execução do IE para modificar configurações de conta de usuário, por exemplo, para configurar para iniciar sempre que o usuário fizer logon. Enquanto era uma meta de design inicial do Windows Vista para usar as elevações com a área de trabalho segura, mecanismo de integridade do Windows e UIPI para criar uma barreira impermeável — chamado um limite de segurança — entre software em execução com direitos de usuário padrão e direitos administrativos, dois motivos impediram que meta alcançada e subseqüentemente foi descartado: compatibilidade de aplicativo e usabilidade.
Figura 1 exibição nome. ’s le fi executável
Primeiro, considere o diálogo de elevação propriamente dito. Ele exibe o nome e o Editor do executável principal que será concedido direitos administrativos. Infelizmente, enquanto o maior número de editores de software é assinar digitalmente seu código, há aquelas que não estão, e há muitos aplicativos mais antigos que não estão assinados. Para software que não está assinado, a caixa de diálogo elevação simplesmente mostra nome de arquivo do executável, que torna possível a malware já em execução em uma conta de usuários e que está observando uma elevação de um instalador de aplicativo Setup.exe não assinado, por exemplo, para substituir o arquivo executável Setup.exe um mal-intencionado sem o usuário seja capaz de dizer (veja a Figura 1 ).
Em segundo lugar, a caixa de diálogo não informar o usuário que DLLs carregará o executável depois que ele seja iniciado. Se o executável reside em um diretório sob controle do usuário, o malware em execução com os direitos do usuário padrão pode substituir qualquer DLLs associadas no local que irá usar o software. Como alternativa, malware pode usar funcionalidade de lado a lado para fazer com que o executável carregar mal-intencionado versões de aplicativo ou sistema DLLs. E a menos que um usuário vigilantly clica no botão Detalhes e examina com cuidado o caminho do arquivo listado para o executável elevador, malware pode copiar o executável para um local nomeado da mesma forma, por exemplo, \ProgramFiles\Vendor\Application.exe (Observe o espaço ausente no que deve ser "Arquivos de programas"), onde ele pode controlar quais DLLs as cargas de aplicativo. Na Figura 2 , tenha copiado um componente do Microsoft Network Monitor para o diretório C:\ProgramFiles criadas pelo usuário que é controlável pelo usuário e iniciado-lo.
Figura 2 Launched cópia do componente do Monitor de rede Microsoft.
Finalmente, para compatibilidade de aplicativo, aplicativos elevados compartilham estado substancial com o ambiente do usuário padrão que um aplicativo mal-intencionado poderia usar para influenciar o comportamento de um aplicativo elevado. O exemplo nítido isso é o perfil do usuário do Registro, HKEY_CURRENT_USER (HKCU). Que é compartilhado porque os usuários esperam que as configurações e extensões que eles registram como um usuário padrão para trabalhar em aplicativos elevados. Malware poderia usar extensões de shell registradas em HKCU para carregar em elevados aplicativos que usam qualquer um dos shell navegação caixas de diálogo, como abrir e salvar arquivo. Outros tipos de estado também são compartilhados, principalmente o objeto de nome de base namespace, onde aplicativos criar sincronização e objetos de memória compartilhada. Malware pode tirar proveito dos compartilhamento para atacar um objeto de memória compartilhada usado por um aplicativo elevado, por exemplo, para comprometer o aplicativo e, em seguida, o sistema.
Como para o mecanismo de integridade do Windows, sua eficácia como uma barreira é limitada pelos problemas de elevação que já mencionei, mas ele também tem limitações devidas a compatibilidade de aplicativos. Para um, UIPI não impede que aplicativos de usuário padrão de desenho na área de trabalho, algo que pode ser usada para induzir o usuário interagir com aplicativos elevados de uma forma que concede direitos administrativos de malware. Mecanismo de integridade do Windows também não fluam através da rede. Um aplicativo de usuário padrão em execução em uma conta PA terá acesso aos recursos do sistema em um sistema remoto no qual essa conta PA tem direitos administrativos. Essas limitações de endereçamento possui ramificações de compatibilidade de aplicativo principal. Dito isso, que é continuamente está vendo maneiras de melhorar a segurança do sistema, por exemplo, melhorando o IE de modo protegido, ao mesmo tempo endereçamento problemas de compatibilidade de aplicativos e trabalhar de perto com os desenvolvedores de software.
Portanto, quanto proteção contra malware você obtém ao executar em uma conta PA do Windows Vista com UAC ativado? Primeiro, lembre-se que qualquer uma disso importa, malware tem de obter no sistema e iniciar a execução em primeiro lugar. Windows tem muitos recursos de proteção em camadas, incluindo prevenção de execução de dados (DEP), (Address Space carga RANDOMIZATION), Internet Explorer de modo protegido, o IE 8 SmartScreen Filtro e Windows Defender que ajudam a impedir que malwares Obtendo no sistema e executar.
Como para o caso em que malware, de alguma forma, consiga obter em um sistema, como autores de malware (como desenvolvedores legítimos) tem assumido usuários executam com administrativas direitos, a maioria dos malware não funcionará corretamente. Que sozinho poderia ser considerado um benefício de segurança. No entanto, malware que é chegado em um sistema e criado para explorar as oportunidades que consiga obter direitos administrativos na primeira vez o usuário eleva — mas o malware mesmo não precisa esperar por uma elevação "real" porque ele pode precipitate que seria ainda mais segurança usuários consciente enganar. Demonstrei publicamente como malware pode seqüestrar o processo de elevação em Meu Elementos internos do UAC e Limites de segurança do Windows apresentações (a demonstração está no minuto 1: 03 a conversa de limites de segurança). Lembre-se, no entanto, se o malware for iniciado em execução, ele pode realizar a maioria das coisas que quer fazer com direitos de usuário apenas padrão, incluindo configurando para executar sempre que o usuário fizer logon, roubar ou excluir todos os dados do usuário ou até mesmo se tornando parte um botnet que o malware.

O que há diferente no Windows 7
Mencionei algumas das operações no Windows 7 que agora podem ser executadas por usuários padrão, mas como o blog E7 postagem no UAC explica, nós também reconhecido que nós pode tornar a experiência do Windows mais suave sem sacrificar sua metas do UAC. Muitos usuários reclamar sobre o fato de que próprio Windows Vista com freqüência solicita direitos administrativos quando executarem operações comuns de gerenciamento de sistema. É de nosso interesse, porque é o intuito de nossos clientes, para tornar o Windows funcionam bem para ambientes de usuário padrão. No entanto, solicitações de elevação não instruir ou incentivar nos para fazer isso, mas eles forçar os usuários clicar em um segundo tempo por meio de uma caixa de diálogo que a grande maioria dos usuários não lido. Windows 7, portanto, propus a minimizar os avisos de experiência do Windows padrão e permitem que os usuários que executam como administradores para controlar sua experiência de prompt.
Para fazer isso, nós refatorado ainda mais o sistema, que alguém com direitos de usuário padrão pode executar mais tarefas e reduzimos o número de solicitações em vários cenários multi-prompt (por exemplo, instalar um controle ActiveX no Internet Explorer). Windows 7 também introduz dois novos UAC modos de operação que são selecionáveis em uma caixa de diálogo configuração nova do UAC (consulte a Figura 3 ). Você pode abrir a caixa de diálogo Ir para o painel de controle, em contas de usuário, em contas de usuário e, em seguida, clicando em Alterar configurações de controle de conta de usuário. (Você pode também obtê-lo clicando no link Alterar quando notificações aparecem em um prompt de elevação ou passar pelo centro da ação.)
Figura 3 dois novos UAC modos operacionais que são selecionáveis em um novo UAC configuração diálogo.
A configuração padrão, mostrada na Figura 3 , é um dos novos níveis. Ao contrário sempre notificação, que é a seleção na parte superior do controle deslizante e é idêntico ao modo padrão do Windows Vista, o padrão do Windows 7 solicita ao usuário somente quando um executável do Windows não solicita elevação; o comportamento para as elevações não-Windows é o mesmo que era para o Windows Vista.
A próxima posição de controle deslizante para baixo é a segunda nova configuração e tem o mesmo rótulo, exceto com "(não dim minha área de trabalho)" anexado a ele. A única diferença entre o que e o modo padrão é que solicita acontece em área de trabalho do usuário em vez de área de trabalho segura. A vantagem de que é que o usuário pode interagir com a área de trabalho enquanto um prompt está ativo, mas como mencionado anteriormente, o risco é que software de acessibilidade de terceiros pode não funcionar corretamente na caixa de diálogo prompt.
Finalmente, a posição do controle deslizante inferior desativa totalmente de tecnologias do UAC, para que todos os softwares em execução em uma conta PA é executado com direitos administrativos, virtualização de arquivo do Registro e sistema são desativadas e IE de modo protegido está desativado. Embora haja há avisos nesta configuração, a perda do IE de modo protegido é uma desvantagem significativa desse modo.

Elevação automática
O motivo que elevação de executáveis de Windows (mais) em duas configurações de meio não resulta em um prompt é que o sistema "eleva automática" Windows executáveis. Primeiro, o que Windows definir como um executável do Windows neste contexto? A resposta depende de vários fatores, mas devem conter duas coisas: devem ser assinado digitalmente pelo editor Windows, que é o certificado usado para assinar todos os códigos incluído no Windows (ele não é suficiente para ser assinado pela Microsoft, para software Microsoft que não é fornecido no Windows não está incluído); e ele deve estar localizado em uma das poucas pastas "segura". Um diretório seguro é aquele que os usuários padrão não é possível modificar e eles incluem %systemroot%\System32 (por exemplo, \Windows\System32) e a maioria dos seus subdiretórios, % SystemRoot%\Ehome, bem como alguns diretórios em % ProgramFiles % que incluem o Windows Defender e diário do Windows.
Além disso, dependendo se o executável for um .exe normal, MMC.exe ou um objeto COM, elevação automática possui regras adicionais. Windows executáveis (como recém-definidos) da variedade .exe auto-elevem se especificam a propriedade autoElevate em seu manifesto, que também é onde aplicativos indicam ao UAC que desejam direitos administrativos. Eis aqui o Sysinternals Sigcheck utilitário despejar o manifesto para Gerenciador de tarefas (Taskmgr.exe) com o comando "sigcheck –m % systemroot%\system32\taskmgr.exe", que mostra que o Gerenciador de tarefas é tiver optado por auto-elevação, conforme mostrado na Figura 4 .
Figura 4 O autoElevate propriedade
Uma maneira fácil de localizar automática-elevar executáveis em um diretório árvore é usar o utilitário Sysinternals Strings com um comando como este:
strings –s *.exe | findstr /i autoelevate
Também há uma lista codificada de executáveis do Windows que obter o tratamento de elevar automática. Desses executáveis do Windows também enviar externos ao Windows 7 e devem ser poderá ser executado em sistemas de nível inferior onde a presença da propriedade autoexecute resultaria em erro. A lista inclui Migwiz.exe, o Assistente de migração, pkgmgr.exe, o Gerenciador de pacote e Spinstall.exe, o instalador do Service Pack.
O MMC, MMC.exe, obtém tratamento especial desde que ele hospeda muitos dos sistema Gerenciamento snap-ins, que são implementados como DLLs. MMC.exe inicia com uma linha de comando que especifica um arquivo .MSC que lista o MMC snap-ins carregar. Quando o Windows vê MMC.exe pedir direitos administrativos, o que ele faz quando iniciados a partir de uma conta PA, ele valida que MMC.exe um executável do Windows e, em seguida, verifica o .MSC. Para ser qualificado para elevação automática, o arquivo .MSC deve satisfazer os critérios de executáveis do Windows (assinados pelo Windows em um local seguro) e ele deve ser listado em uma lista interna de elevar automática .MSCs. Essa lista inclui praticamente todos os arquivos .MSC fornecidos com o Windows.
Por fim, objetos COM podem especificar a necessidade de direitos administrativos com um valor de registro em sua chave do registro criando uma subchave denominada elevação com um valor denominado Enabled é definido como 1. Figura 5 mostra a chave do Registro para copiar/mover/renomear/excluir/link objeto do shell que o Explorer usa quando um usuário executa uma operação de arquivo do sistema em um local de sua conta não tiver permissões para.
Figura 5 chave de registro do shell
Para um objeto COM ser auto-elevado, também deve ser um executável Windows e deve ter sido instanciado por um executável Windows de. (O executável instanciando não precisa ser marcada para auto-elevação, porém.) Quando você usa o Explorer para criar um diretório no diretório % ProgramFiles % de uma conta PA, por exemplo, a operação automática-elevará porque o objeto COM solicitações de elevação, DLL do objeto é um executável do Windows, e Explorer é um executável do Windows.

Automático-elevação e objetivos do UAC
Portanto, o que há por trás de todas as regras especiais de elevação de automática? Escolha o que elevar automática e o que não a foi interativa, a pergunta, "pode, inadvertidamente, um desenvolvedor de aplicativos ou dependem muito direitos administrativos, aproveitando elevar automática?" Como cmd.exe pode ser usado para executar scripts em lotes por meio de argumentos de linha de comando e média de usuários ter há necessidade de executar prompts de comando elevados (mais ainda não souber que um prompt de comando é), não foi declarado para elevação automática. Da mesma forma, Rundll32.exe, o executável que hosts controlam painel plug-ins, não automática-elevar na versão final do Windows 7 porque seu elevação não é necessária para qualquer tarefas comuns de gerenciamento, e se auto-elevado, sua capacidade de hospedar DLLs arbitrárias por meio de sua linha de comando pode fazer um desenvolvedor exigir direitos de administrador sem perceber.
Os usuários finais sido pedir ao Windows fornecer uma maneira de adicionar aplicativos arbitrários para o auto-elevar lista desde o Windows Vista beta. O motivo citado normalmente é que alguns aplicativos de terceiros usarem com freqüência força constantemente clicar em um prompt de elevação como parte de sua rotina diária. Windows 7, assim como o Windows Vista, não fornecer como um recurso. Compreendemos aborrecimentos e pode haver um motivo legítimo para que esses aplicativos não podem executar sem direitos administrativos, mas o risco é muito alto que os desenvolvedores irão evitar corrigir seu código para trabalhar com direitos de usuário padrão. Mesmo se obter a lista de quais aplicativos elevados automática só estava acessível pelos administradores, os desenvolvedores simplesmente podem alterar seu programa de instalação aplicativo, que requer uma elevação única, para adicionar seus aplicativos para a lista. Em vez disso, escolhemos investir no instruir e trabalhar de perto com desenvolvedores de aplicativos para garantir que seus programas funcionem corretamente como um usuário padrão.
Várias pessoas observado que é possível que um software de terceiros em execução em uma PA conta com direitos de usuário padrão para tirar proveito de elevação de automática para obter direitos administrativos. Por exemplo, o software pode usar o WriteProcessMemory API para injetar código Explorer e o CreateRemoteThread API para executar esse código, uma técnica chamada injeção de DLL. Desde que o código está sendo executado no Explorer, que é um executável do Windows, ele pode aproveitar os objetos COM que elevem automática, como o objeto copiar/mover/renomear/excluir/link, modificar chaves de registro do sistema ou diretórios e fornecer os direitos administrativos software. Ao true, estas etapas exigem intenção deliberadamente, não triviais e, portanto, não são algo nós acreditamos que desenvolvedores legítimos poderiam optar por versus corrigir seu software para executar com direitos de usuário padrão. Na verdade, é recomendável contra qualquer desenvolvedor de aplicativo levando uma dependência no comportamento elevação no sistema e esse teste de desenvolvedores de aplicativo de software em execução no modo de usuário padrão.
Observação acompanhamento é que o malware pode obter direitos administrativos, usando as mesmas técnicas. Novamente, isso é verdadeiro, mas como mencionei anteriormente, o malware pode comprometer o sistema via elevações solicitados bem. Da perspectiva do malware, modo de padrão do Windows 7 é não mais ou menos seguro que o modo sempre notificação ("modo de vista") e malware que considera direitos administrativos ainda interromperá quando executado no modo de padrão do Windows 7.

Conclusão
Para resumir, o UAC é um conjunto de tecnologias que tem um objetivo geral: para possibilitar que os usuários executem como usuários padrão. A combinação de muda para Windows que permitem aos usuários padrão mais operações que anteriormente necessários direitos administrativos, virtualização de arquivo e registro e solicita que todo o trabalho em conjunto para realizar esse objetivo. A linha inferior é que o modo de UAC do Windows 7 padrão torna experiência um usuário ’s PA mais suave reduzindo prompts, permite que eles controlar qual software legítimo pode modificar seu sistema e ainda atinge objetivos ’s UAC de habilitar mais software seja executado sem direitos administrativos e continuar mudar o ecossistema de software para o software de gravação que funciona com direitos de usuário padrão.

Mark Russinovich é um colega da área técnica da Microsoft na divisão de serviços de plataforma e.

Page view tracker