It doesn't have a whitelist (
see).
It shouldn't have one either. If Microsoft added a whitelist, it would completely undermine User Account Controls (UAC) purpose which is to force software developers to write their applications so they work correctly in a standard user environment. By adding a whitelist, software developers would take advantage of it and would continue to write their applications in that they assume administrator rights. Every time a user runs one of their applications and are presented with an elevation dialogue, if they have a choice between having to accept that elevation dialogue every time they run that particular application or they simply need to accept that elevation dialogue once and then add it to the white-list so in future, the application automatically gets granted administrator rights, they are obviously going to do the latter.
Mark Russinovich said:
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.
Inside Windows 7 User Account Control
mrk said:
If you're fairly competent however and understand that there is a very small risk that something could compromise your machine in a moment of human error on your part then you can disable it like many people (including myself) have. In fact it's disabled on all my home computers and has been since Vista came out (all now on 7) and I am happy to report even my less computer friendly family members have not fallen ill to human error yet
Certain aspects of User Account Control are not quite as a big of a "security" feature as some would think and their real purpose lay elsewhere. In brief, User Account Control is a tool to enable users to run a security feature known as standard user accounts.
Ideally, it would be great if everyone would use a standard user account for their everyday to day tasks and then switch to a dedicated administrator account whenever they need to do any operations which require administrator rights. This would be the most secure way of doing things. However, for the vast majority of users, the inconvenience of doing so would be too great and once they have had to switch to an administrator account once, they wouldn't want to switch back and would simply stay in the administrator account. The elevation dialogue feature of User Account Control is there to counter this issue. When the user is running in a standard user account, if they need to do an operation which requests administrator rights, they will receive an Over The Shoulder (OTS) elevation dialogue which will ask them to enter the credentials of an administrator account to continue with that given operation and ignoring the need to switch accounts.
Moving onto the administrator accounts. The account which is created upon installation in Windows Vista and Windows 7 and any administrator accounts which are created thereafter from the user accounts section of the control panel is a Protected Administrator (PA). When the user logs in, they are running in a mode called Administrator Approval Mode (AAM) where they are given two identifies, one with standard user rights and the other with administrator rights. The standard user identity is used by default. When an operation requests administrator rights, the user will receive a consent elevation dialogue which they would simply need to accept to continue with that operation.
Since the default account in Windows Vista and Windows 7 runs with standard user rights, software developers must now assume everyone will be running with standard user rights. This forces them to start writing their applications so they work correctly in a standard user environment.
Mark Russinovich said:
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.
*Snip*
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.
Inside Windows 7 User Account Control
Whilst running as a Protected Administrator is securer than running as an administrator with User Account Control disabled, the security benefits that you get from running in Administrator Approval Mode are a side effect of it's primary purpose which is to force software developers to write their applications so they work correctly in a standard user environment. It's still recommended to use a standard user account as your main account.
When you elevate, either from a standard user account or a Protected Administrator account, you are introducing a security risk. Anything malicious could then potentially gain administrator rights due to the opportunities the elevations present and the shared state between the standard user environment and processes running with administrator rights.
Mark Russinovich said:
Elevations and Security Boundaries:
It’s important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. User accounts are an example of a security boundary in Windows because one user can’t access the data belonging to another user without having that user’s permission.
Because elevations aren’t security boundaries, there’s no guarantee that malware running on a system with standard user rights can’t compromise an elevated process to gain administrative rights. For example, elevation dialogs only identify the executable that will be elevated; they say nothing about what it will do when it executes. The executable will process command-line arguments, load DLLs, open data files, and communicate with other processes. Any of those operations could conceivably allow malware to compromise the elevated process and thus gain administrative rights.
Inside Windows Vista User Account Control
This is why the elevation dialogues are not for security, but convenience. Without the elevation dialogues, no one would run either in a standard user account or as a Protected Administrator and software developers would continue to write their applications assuming everyone has administrator rights and there would be no progress.
Mark Russinovich said:
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?
Inside Windows 7 User Account Control
Mark Russinovich said:
Because elevations and ILs don’t define a security boundary, potential avenues of attack , regardless of ease or scope, are not security bugs. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption.
PsExec, User Account Control and Security Boundaries
Whilst it is possible for anything malicious to gain administrator rights from either a Protected Administrator or a standard user account, it is a lot more difficult to do from a standard user account.
Mark Russinovich said:
Elevated AAM processes are especially susceptible to compromise because they run in the same user account as the AAM user’s standard-rights processes and share the user’s profile. Many applications read settings and load extensions registered in a user’s profile, offering opportunities for malware to elevate. For example, the common control dialogs load Shell extensions configured in a user’s registry key (under HKEY_CURRENT_USER), so malware can add itself as an extension to load into any elevated process that uses those dialogs.
Mark Russinovich said:
Even processes elevated from standard user accounts can conceivably be compromised because of shared state. All the processes running in a logon session share the internal namespace where Windows stores objects such as events, mutexes, semaphores, and shared memory. If malware knows that an elevated process will try to open and read a specific shared memory object when the process starts, it could create the object with contents that trigger a buffer overflow to inject code into the elevated process. That type of attack is relatively sophisticated, but its possibility prevents OTS elevations from being a security boundary.
Inside Windows Vista User Account Control
User Account Control is Microsoft's step to the
Standard User Vision. By forcing Independent Software Developers to write their applications so they work correctly in a standard user environment by shipping the default account in Windows Vista and Windows 7 as a Protected Administrator, this will in turn reduce the amount of elevation dialogues a user receives in a session which will then hopefully lead to more people running in a standard user account. I'll expect in Windows 8 or certainly the next version of Windows after, the default account will be a standard user account.
mrk said:
I#m sure some will be along shortly to counter argue the finer points of UAC and its benefits which is all well and good but it's just not for people like me and perhaps even yourself, people who just want to take control of files and applications and not have to elevate permission every single time or encounter broken applications because the application isn't using a signed driver for example.
From a users perspective, User Account Control is a tool to enable users to run with a security feature known as standard user accounts, as said earlier. If you want to run as a full blown administrator then you are not going to like User Account Control very much. However, if you would like to run in a standard user account or at least start making that transition, then User Account Control is a brilliant tool.
