Welcome to MSDN Blogs Sign in | Join | Help

Why User Account Control (UAC)?

Running as an administrator today can be very costly. When you run as an administrator, every application that you launch can potentially use your account’s privileges to write to system files and the registry and to modify system-wide data. Common tasks like browsing the Web and checking e-mail can become unsafe in this scenario.

Enterprises also face a daunting task of enforcing desktop standardization in an environment where most users continue to run as local administrators. Because each user can install/uninstall applications and adjust system and security settings at will, IT departments often cannot gauge the holistic health and security of their environments and thus increases their Total Cost of Ownership (TCO).

The Standard User account is an account that has no machine administrative privilege.  This account type has been available in Windows NT-based operating systems since Windows NT 3.1, so why do people continue to run as administrator? Unfortunately, many applications today are unable to run with a Standard User’s privileges and require administrative access. Even some simple Windows tasks do not work if you are not an administrator, like changing the time zone.

How does User Account Control work?

Knowing this was a huge issue for customers and Microsoft as well, the User Account Control (UAC) team set out to find a way to make it easy for everyone to run as a Standard User. The first step was to identify which applications / tasks unnecessarily require administrator privileges. The UAC team has been working with different software companies to help them accomplish this task. All Microsoft applications and Windows features are also going through this same review process. This change takes a lot of collaboration and effort, but it is a big step in the right direction to help make Windows more secure.

The next step was to redesign the way that user accounts work in Windows. The following section lists Windows Vista user accounts and groups.

  • Built-in Administrator account: The standard built-in Administrator account, and a member of the Local Administrators group. This account has full access throughout the operating system.
  • Local Administrators group: This group’s members have the highest potential level of administrative access to the local computer but are always logon restricted.
  • Standard Users group: This group’s members are unable to make system-wide changes, like installing applications and changing system settings, without an administrator providing his/her credentials during an Over the Shoulder (OTS) credential prompt. An OTS credential prompt occurs when a standard user attempts to perform a task that requires administrative privileges.

The Power Users group was deprecated from Vista since many tasks that formerly required privileges granted to this group are now available to the Standard Users group. For instance, Standard Users can now install printers and respond to Windows Firewall notifications.

What makes the UAC user account model different from previous models is that all users, Administrators and Standard Users, run with standard user access by default. Only the Built-in Administrator account runs with a full access token by default. When an administrator logs on to Windows Vista, two versions of the account’s access token are created: one with the full rights and privileges and another that is stripped of the administrative privileges. The latter is called the standard user access token and is used to initially invoke Explorer after the administrator logs on. Because most applications and processes are launched through Explorer, they inherit this Standard User access token and run with its limited privileges.

What happens when you need to change a system setting?

In previous versions of Windows, you would have had to either log off with your Standard User account and then log back in as a local administrator or to use some form of RunAs to invoke the application with an administrator account’s privilege. UAC, however, identifies which applications require administrative privileges and prompts you for confirmation –based on policy-- when you want to use those privileges. This process is called an elevation prompt. If you approve the prompt, your account’s full administrator access token is used to launch the application.

So, what about Standard Users? How do they install applications? 

Standard Users can in context install applications and perform other administrative tasks if they are able to provide credentials for an account that is a member of the Local Administrators group. For instance, when a Standard User attempts to install an "all users" application, UAP launches an OTS credential prompt to ask the user to provide administrative credentials.

What are some User Account Control benefits?

UAC reduces the attack surface by ensuring that all users run with the least amount of privileges that they need to perform a task.  By reducing the attack surface, you reduce the time and effort associated with managing a computer.

The following are also benefits of UAC.

  • Reduced impact of “spyware” and “malware”: Since rogue applications will require administrative privileges to install and perform their tasks, running with a standard user access token will help reduce their impact. If a software bug is exploited, the damage will be contained to the files and folders that the user has privileges to, and not to the entire computer.
  • Lower total cost of ownership: IT departments will notice reduced cost of ownership since they can now standardize and manage their desktops.  On average, managed desktops cost 40% less annually than unmanaged desktops. Home users will also see a reduction in costs due to the reduction of impact that of “spyware” and “adware” that may have formerly wreaked havoc on their computer.
  • Greater parental control: Parents will be able to use Vista parental controls by running as a local administrator and having their children run with standard user accounts. Previously, if the children also had administrator accounts, parental controls could be easily circumvented.
Published Thursday, October 13, 2005 12:28 PM by UAP

Comments

# re: Why User Account Protection (UAP)?

It's not clear how this differs from the existing arrangement in XP where, if you put explorer.exe in the SRP so that it always runs with user rights, all logons including administrative logons run everything launched from the shell with user rights. If you do this then anything that requires administrative rights needs to be run using "runas" or some other form of secondary logon but with your own credentials.

If you do this any program lanched from a task manager invoked from ctrl-alt-delete will run with admin privileges without requiring a secondary logon. will vista block this?

This is one of the methods we reviewed when looking for ways to give our users delegated rights to perform such tasks as install software and local printers, without having to spend too much time extracting malware from their systems. Our users are generally responsible, so we are mainly protecting from mistakes rather than from the ill-intentioned.

Obviously a key factor in the success of this kind of scheme is whether software will run after install without excessive rights. Elsewhere I've read comments that suggest that Vista will have special features to allow poorly written programs to be run, by giving the program the impression that it has permissions (e.g. to write in the system directory) when it is only working with a copy)

One of the largest problems that arises after you have allowed the user to install software by elevating their rights, is that the software doesn't work unless it is run with elevated rights. An easy way to deal with one common cause of this (lack of permissions to write in the directory in which the program is installed) is to elevate their rights for the install, and to leave them as the owner of any files and folders they create using these elevated rights. It only works when only one user is involved. In XP this ownership model is the default. It is obviously less secure than leaving the ownership of the objects created with the administrators group.

What will Vista's default be? If programs were properly behaved or Vista could successfully deceive them about their rights, then the option of setting the ownership of files created by any administrator logon to be owned by the administrators group is best.

Clearly if a program is logo compliant it shouldn't be installed by elevating your own credentials if you end up owning the the program.

Finally (well for this comment) when you talk about enabling users to install local printers this will presumably only include those printers that can be installed from straightforward .inf files. Increasingly modern printers come with large installation systems that will require admin rights to install. will the printers created have different permissions to those in XP. Currently we give interactive manage printer and document rights to local printers: If you can physically pull the plug on another users print job, why not do it in software? More prosaically some all-in-ones wouldn't go back online as printers for ordinary users. (without manage printer permissions)
Monday, October 17, 2005 6:34 PM by Mike Rickard

# re: Why User Account Protection (UAP)?

Great question. You solution works fine on XP given that all applications get invoked via ShellExecute() but if you programmatically call CreateProcessAsUser you will invoke an admin process silently. You also loose admin scenarios like sharing and anything that runs inside an IShellFolder. The application running as Standard User on the XP desktop can “ask” the Explorer to do work for it and the Explorer will happily do the work as admin. It is a good solution on XP because the exploit writers are not looking for it. If we tried to ship this as a general solution however, there would be easy workarounds for the exploit writers to get elevated privileges.

The problem highlights why we needed a strong isolation mechanism to pull of User Account Protection initiative in Vista. In Vista, applications running as Admin and Standard User can exist on the same desktop. But that means that Admin apps need to be protected from attack by the Standard Mode apps. We had to build protection from Standard Mode apps sending keystrokes, injecting threads, and injection data into the admin apps.

Yes, this is blocked in Vista. Even when you log on with a user that is a member of the local administrators group, the Explorer will run as Standard User. And “lower” integrity apps are disallowed from scripting or injecting into “higher” integrity apps.

We thought of going down similar paths to your suggestion of “loosening” the ACLs on files that are written in admin locations, but decided to take the potential app compat hit by going down a more secure path. The problem is, if you set an ACL to leave the user as “owner” of the file, we would still leave in attacks where one user can write to a file an affect the experience of another user. For example, in older versions of Office, the Template.dot files live in Program Files\Office\...\template.dot. If we loosen the ACL on this file, and user1 is allowed to write to it, he can leave a Word Macro that attacks User2 when User2 loads WinWord and WinWord goes and gets the template.dot. Instead, we opted to give each User1 and User2 their own copy of template.dot. Let me use the example of a computer game to show the consequence of this method: If two kids are playing the same game, and the game writes the high score to Program Files\Game\highscore.dat, both kids will have their own copy (redirected) of highscore.dat. Consequently, both kids think they have the high score.

We correctly leave the owner as Admin in Vista. (Yell if you see differently)

I hear you on the printer installation. We have a general problem here in that printers need to be deployable in the enterprise. In the home, this is less of a concern.
• In the enterprise, if you want your printer to be installed and deployable, you need to separate the drivers from the applets that are commonly shipped with the drivers. This is true today. We are working with vendors to have them understand the need for this split.
• In the home, this is less of a problem because the home admin is elevating to run an admin setup package that installs both the printer driver and the applets.

Great questions! Keep ‘em coming!
Monday, October 17, 2005 9:29 PM by UAP

# Another security strategy - Using Least Privilege

I recently read about Programming on Windows Authenication, I got a lto of result after searching. I...
Monday, February 13, 2006 10:27 PM by .NET MVP KenLin's Blog

# Is your MSI Package ready for Vista?

Imagine a blog entry where I explain how to test your MSI package against UAC without Vista.

# Vista User Account Control, Seguran

Wednesday, April 05, 2006 8:36 PM by Rui Quintino

# Using RunAs in Windows XP

Found this interesting blog entry while researching part 2 of my UAC article. One of the main problems...

Wednesday, January 10, 2007 12:52 AM by Slater in Seattle
New Comments to this post are disabled
 
Page view tracker