| Historical Problem with Windows | Differentiation of an administrator from a standard user has been common in mainframes and servers for decades. This had an obvious security component, but also an administrative component, in that it prevented users from accidentally changing system settings. Microsoft home operating systems before the introduction of Windows XP running on the NT kernel did not have a concept of different user accounts on the same machine, and all actions were performed as administrator. Windows NT introduced multiple user accounts, but in practice most users of XP continued to operate as administrator for their normal operations. |
| Application Compatibility | At the time that Windows XP introduced the NT kernel to the home user; a primary goal was support for the large collection of Windows applications that were constructed for Windows 9x with no concept of administrator versus standard user. The expedient answer was to give the default user on an XP system administrative privilege. As a result any process running as that user could change any attribute of Windows. Thus most of the legacy Windows applications would run on Windows XP, but the result was that both the installation and operation of the application had full control of the entire computer. |
| Separate Administrator Accounts | UNIX computers have a long history of encouranging users to avoid running as administrator (aka superuser) for nornal operations to avoid inadvertant configuration problems. Versions of Windows NT and Microsoft applications have encouraged the use of separate non-administrator user logins, esipecially for domain admins, but the uptake has been slow. On a UNIX system any user that wants to run an app that changes system setting needs to run that app as system. Any UNIX user with a system password can run as the local system. Even when separate accounts exist on either Windows and UNIX, users have a tendency to perform dangerous activities when logged into the comptuer using an account with administrator privilege. Without some control over which applications are allowed to run with system privilege, the security of the entire system is placed into the hands of every user with administrative privilege. |
| Separation of Apps and Content | The goal of UAC (discussed below) is the protection of the system from applications that should not be trusted with privileges that enable the app to change the security settings of the operating system. An early requirement derived from that goal is that no content on the computer should impact applications that do change system settings unless that content is also trusted at the same high level. The impact of this requirement is that all apps and the content that drives them need to labeled in some way with a secure attribute that the operating system can use to determine whether that content can be used as input to an app running with systerm privileges. On a UNIX system any user that wants to run an app that changes system setting needs to run that app as system; thus the labeling of content is implicit in the identity of the logged on user account. On Windows a more general solution is required. |
| Mandatory Integrity Control | UAC is the largest deployment of MIC ever. It is perhaps an accident of timing that the isolation mechanism chosen for UAC was integrity levels. Windows, like most other modern operating systems, separated content by user account. That means that content from one user is not available to other users unless the owner makes an explicit decision to allow that access. Giving that existing security boundary between one user and another, it would have been easy for developers to use separate accounts for content and applications, but that would have lost the identity of the user making the change. For better forensics and accountability, the identity of the user making system changes should be maintained. The method chosen by Windows Vista was a new access control entry (ACE) for integrity. |
| Integrity Levels | Windows maintains the integrity level in the System Access Control List (SACL) of each object and in the user token together with UI access for UIPI. From a practical design point of view the levels are low, medium and high, but the complete list for Vista includes: | Level | Definition | | System | This level is reserved for processes or state related to services running under the Local System, Network Service, or Local Service accounts. It is assumed that this level has the complete ability to impact the system. | | High | This level is reserved for applications or state relating to processes that run interactively with the ability to affect the entire system. For example, this level would be used if a process was run by a user with a privileged group on their token; e.g. Administrators or Backup Operators | | Hybrid | An diate level just above Medium used when the logged on user has some priveleges intermediate between Medium and High; e.g. Network Configuration Operator | | Medium | This level is the default level. Any state or processes created by a member of the Users group or a “Protected Administrator” confers this level. It is assumed that processes running at this level cannot have machine-wide impact but can affect the user’s state. If there is no marking on an object it is assumed to have this level. | | Low | This level is the first level that limits the execution privileges below the associated user’s privileges. At this level, code can execute with the ability to read the data on the system but it does not have the ability to affect this state. |
|
| UAC does not protect User Content | Integrity control does not imply content access control. The practical effect of this fact is that while users are safer running UAC, their content is not protected from malware. In other words, the user does not see that the integrity of the system is protected, but they do see that their own content, like access to bank accounts, is still released to any malware running with a standard user token. As a result the home user can not appreciate the value provided for the inconvenice of all those annoying user prompts. |
| User Interface Privilege Isolation (UIPI) | Protection from Windows Message (shatter) attacks from low privileged processes driving the input of higher privileged processes. |
| Virtualization | File and Registry Virtualization is active when UAC is turned on, user settings and configuration files may be installed to a different place (a system directory rather than a user-specific directory) if UAC is switched off than they would be otherwise. By the time Windows Vista was released in November 2006, Microsoft had drastically reduced the number of operating system tasks that triggered UAC prompts, and added file and registry virtualization to reduce the number of legacy applications that trigger UAC prompts |
| Heuristics | In the absence of manifest or other statement of the privileges that the application requests, Windows will apply heuristics, to determine whether or not the application needs administrator privileges. For example, if Windows detects that the application is a setup program, from clues such as the filename (setup.exe, patch.exe), versioning fields, or the presence of certain sequences of bytes within the executable, in the absence of a manifest it will assume that the application needs administrator privileges and the user's choice to intall the application is sufficient to run the install. |
| Application Manifest | A major effort for Windows Vista was the integration of managed code including a manifest to described the expected behavior of the applications. Most of the managed code features were removed except for the manifest which has a trustInfo tag that can request a specific previlege level. For example an application can indicate that it needs administrative privilege by setting requestedExecutionLevel to "requireAdministrator". As applications require more specific privileges expect this range of settings to grow over time. |
| The missing features | There are some features that are so obviously needed that they were created by third party developers soon after Vista shipped. The biggest one relates to marking some apps as safe to run with admin privilges. UAC does ship with support for the application manifest, described above, but nothing that allows users to accept existing applications in the field. Some solutions for that problem are available as the Elevator from Martin Zugec or BeyondTrust. |
| Directory Structure | There is an on-going debate about whether the right abstraction for files is inheritance of attributes from the directory that contains the file, or attributes that are directly attached to the file. This distinction becomes important when a file is moved from on directory to another. Should the file carry attributes with it, or acquire the ones from the new location? In the case of Windows, either use case is supported. For the use of UAC and protected mode the decision has been that a new directory is created for content with low integrity. |
Protected mode UAC spreads to other applications | Windows Vista shipped in January 2007 with Internet Explorer 7 running most web pages in "Protected Mode"; meaning that the IE process rendered the web page with a restricted (low integrity) token. IE aslo created an instance running with full user previleges and used a broker from the restricted IE instance to write to user files and the registry. Symantec Antivirus Products, supportes UAC. Google and Adobe adopt Protected Mode Browsing and use the same broker technique to perform actions that need full user privilege. Office 2010 will display Word and other documents in a preview process running in protected mode as should all document previewers written since Vista shipped. These features require UAC and will not provide any protection if UAC is disabled. Protected mode = low = restricted token = same LUID |
| Enterprise Configuration Information | UAC comes with a large number of configuration settings that are described on Technet on the Microsoft web site. That site also contains a good introduction to UAC for enterprise architects and administrators. Microsoft has heard the many problems encountered with Vista installations, including UAC, and published 'Five Misunderstood Features in Windows Vista" to try to help ease deployments. Information on using UAC with WIndows 7 can be found on this site. |
| Developer Support Information | Microsoft's developer network describes the right way to implement UAC, but some of the most helpful information for app developers, especiaclly for legacy apps, is found on external sites like The Code Project. |
| The Principle of Least Privilege & LUA | The principle of least privilege specifies that every compute process have access only such resources as are necessary for its legitimate purpose. This is principle can be applied to user as least-privileged user account (LUA) where the user will be given an account that restricts all applications started by the user to have a restricted set of priviledges. Or the principle can be applied as least user access (also abbreviated LUA) that specifies that any process started by the user will have the least privileges needed to perform the task immediately at hand. For example, a backup process does not need to install software. Hence the backup process should acquire rights only to run backup related functions. Any other privileges like installing software etc. are blocked. Due to the difficulties in both enforcing and the difficulties for the user, this principle is honored more in the breach than in practice. |
| Multiple User Tokens | When logging into Vista as a standard user, a logon session is created and a token containing only the most basic privileges is assigned. In this way, the new logon session is incapable of making changes that would affect the entire system. When logging in as a user in the Administrators group, two separate tokens are assigned. The first token contains all privileges typically awarded to an administrator, and the second is a restricted token similar to what a standard user would receive. User applications, including the Windows Shell, are then started with the restricted token, resulting in a reduced privilege environment even under an Administrator account. When an application requests higher privileges or "Run as administrator" is clicked, UAC will prompt for confirmation and, if consent is given, start the process using the unrestricted token. |
| Protected Administrator (PA) | Some users must run with system level privilege from time to time to perform maintenance functions on the computer. UNIX introduced most developers to the concepts of root (aka system) and superuser (aka administrator). |
| The real reason that UAC was added to Windows Vista | Many reasons have been floated by pundits about the reason for UAC. The historical reason was that during a project to provide for the "Protected Administrator" feature, it became abundantly clear that if applications could be installed by users with administrative privilege, then Windows would lose control of its own security to these applications. It was also clear that Microsoft had little leverage with application deveopers to get them to rewrite their apps to install and run well as standard user. After all the market was dominated by Windows XP which make no such demand on apps (see app compatability above). So the ideas was to disadvantage apps that demanded administrator privilege. Later that sequence of logic was unrolled to the assertion that UAC was designed to "annoy users", but that unrolling was not part of the decision that was made. In fact early metrics show that one success metric was the inverse of the number of user prompts that resulted from UAC. That metric remains to this day. |
| But does UAC help home users? | Some time after UAC was designed to create a protected space for domain administrators, a design review with the head of the Windows Shell added the requirement that UAC also protect the home user that chose to run as administrator. If UAC would help the domain user, the reasoning went, how could Windows not supply the same help to the home user. The problem that this raised was that the user experience had not been designed for the home user as should be apparent from the press after Vista shipped. All of the early press was quite positive about the security benefits of Vista and UAC, but as soon as the security companies and consumer press learned about UAC, the tone quickly changed. In WIndows 7 the user experince changed from UAC to UIC (user in control) and the matra was to "quiet" the UX. |
Pessimists: Is UAC a security boundary? | The simple answer is no, UAC did not implement a security boundary. It is still far too easy for an application to exploit vulnerabilities left in Windows Vista to elevate its privilege to administrator and make any change it wants to the computer system. Windows experts, like technical fellow Mark Russinovich made the case quite clearly. The UX was mostly ignored because it prompted for user consent far too often; which indicated that UAC in Vista failed at one of its primary success metrics in spite of massive efforts late in the product cycle to reduce the frequency of prompts. |
Optimists: Is UAC even a security feature? | A more interesting and more controversial question is whether UAC is a security feature at all. Jim Allchin, the co-president of Windows Vista certainly thought so. And the head of Windows product marketing, Austin Wilson described UAC as a major contributor to the successfull security profile for Vista in the first year after shipping. External experts were also quick to point out how UAC detected code installs, even for root kits. The current president of Windows even called a halt to the efforts by internal experts to label UAC just a convenience feature rather than a security feature. |
| Optimist or Pessimist? | So who is right, the pessimists that see the remaining vulnerabilities, or the optimists that see improved security? It needs to be remembered that MIC was chosen over user account separation for a reason that has not gone away. User account control with separate user accounts is just too clumsy to work for Windows users accustomed to their applications that just work anywhere. With UAC Vista users seem to have gotten more security and reliability features than they were willing to tolerate. Vista deployments suffered from an excess of security and reliability. The security hard-liners should be happy with what has been achieved, but they are focused on the next hurdle, not the past success. |
| User reaction to UAC - delete | The first reviews of Vista and its security features were quite positive. Even today most computer administrators in large enterprises are happy that UAC was introduced are are trying to lock down their users evern more so that the large majority of users will never need adminstrative privileges for any reason. The first squeals of protest against UAC were from the software security providers that looked at UAC as a threat to their revenue streams. It was in their interest to make sure that everyone knew that UAC did not provide a full security boundary. |
| Windows UAC compared to UNIX | At an August 2010 Usenix Security Symposium, Crispin Cowan, the UAC program manager compared the current security of Windows with Unix. He explained that "the annoying UAC pop-up boxes [have] finally spurred many application developers to rewrite their programs... These programs were rewritten so that they did not require full administrative privileges to run, which, in turn, cut down on the UAC boxes and allowed users to slowly grow more comfortable running in more limited, but safer, user modes. Cowan's talk was an extended argument on why Windows 7 is as secure as Unix variants such as Linux. And this security parity came about, in his view, in large part thanks to the fact that Windows Vista was the first desktop version of Windows to not, by default, give each user account full administrative privileges. UAC can be seen as the equivilant of the UNIX Sudo command." While others will surely have different opinions, at least the application pool seems to be moving in the direction of more security on Windows computers. |
| Does UAC reduce customer anxiety? | It is no longer posible to do a customer study that will resolve this question. Too many of the population of computer users already has formed an opinion about UAC. It does seem clear that enterprise administrators like UAC and are now trying to move beyond it to full support for standard user everywhere. That result alone would be complete vindication for the introduction of UAC and all of the pain that users felt as a result of its introduction. How about end users anxiety? Remember that VIsta was the first Windows release after the Windows security stand-down produced Windows XPSP2. Clearly anxiety seems to have reduced, but attacks against applications on user's computers is at an all time high, so UAC and application privilege limitation cannot be said to be responsible for any reduction. |
| Where do we go from here? | New devices are more portable and do not use Win32 APIs. New application APIs are build and application compatiblity is no longer so important. Enterprises are more willing to try to lock down their users' privileges. Let's hope that the new APIs will succeed in providing the least privilege possile to applications and that the applications still have the ability to delight users. I think the good guys are winning. But it is still not clear that UAC should have been inflicted on home computer systems in the way that is was originally. |
| The new legacy - Mandatory Integrity | Mandatory integrity was deployed on Windows Vista in such a way as to allow UAC to function when that would not have been feasible with separate user accounts. As a result MIC is not a security boundary for Windows. Now the question must be asked if it should be strengthened to become a security boundary. Since it was not made a security boundary to allow for application compatibility, there would be an application compatibility hit if it ever were to change into a bona fide security boundary. At the time that MIC was chose over separate accounts there was the beginning of an effort to qualify Windows for MILS - multiple independant level of security - for the DoD. It is sitll possible to upgrade MIC to support military grade isolation using the code that ships in Windows today. That is a goal worth fighting for. |
| |