User Account Control

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by AlleborgoBot (talk | contribs) at 17:15, 14 December 2007 (robot Removing: fi:User Account Control). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Jump to navigation Jump to search
UAC credentials dialog

User Account Control (UAC) is a technology and security infrastructure first introduced with Microsoft's Windows Vista operating system. It aims to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorizes an increase in privilege level. In this way, only applications that the user trusts receive higher privileges, and malware is kept from receiving the privileges necessary to compromise the operating system. In other words, a user account may have administrator privileges assigned to it, but applications that the user runs does not also have those privileges unless it is approved beforehand or the user explicitly authorizes it to have higher privileges.

To reduce the possibility of lower-privilege applications communicating with higher-privilege ones, another new technology, User Interface Privilege Isolation is used in conjunction with User Account Control to isolate these processes from eachother.[1] One prominent use of this in Internet Explorer 7's "Protected Mode".[2]

Overview

Before Windows XP was released, previous versions of Windows targeted at the consumer audience (such as Windows 95, Windows 98 and Windows Me) were all single user operating systems where the user had super user rights. Windows XP, on the other hand, is a multi-user operating system based on Windows NT. This allowed for different user levels and permissions.

However, in Windows XP the first user created when installing the operating system is given administrative privileges by default. As such, most users would use this account for everyday use. This ensured that all software, including malware, was also running with administrator privileges as well, thereby giving it full access to the operating system.

Many legacy Windows applications and even new Windows applications were or are not designed to work without full administrator privileges.[3] Running these as a standard user or even as a power user could lead to errors or strange behavior. As such, it was often normal practice to give users full administrator access when running normally.

In contrast to this, Unix-like operating systems (such as Linux) have always been designed for multiple users, with multiple security levels. Applications made for these platforms have almost always been aware of and compliant with this system.

With User Account Control in Windows Vista and Windows Server 2008, actions that can affect the security and stability of the operating system require the input of an administrator name and password before they are executed. If the user is an administrator, they are not asked to re-enter their password. Instead, a dialog box is shown with the choices to allow or deny the action.

When logging into Windows 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.[4]

Tasks that trigger a UAC prompt

File:Windows Vista Control Panel (shield).png
Operating system commands or actions that require administrator rights (and thus are likely to trigger UAC) are marked with the security shield symbol.

Tasks that will trigger a UAC prompt (if UAC is enabled) are typically marked by a 4-color security shield symbol. These tasks include:[5]

  • Right-clicking an application's icon and clicking "Run as administrator"
  • Changes to files or folders in %SystemRoot% or %ProgramFiles%
  • Installing and uninstalling applications
  • Installing device drivers
  • Installing ActiveX controls
  • Changing settings for Windows Firewall
  • Changing UAC settings
  • Configuring Windows Update
  • Adding or removing user accounts
  • Changing a user’s account type
  • Configuring Parental Controls
  • Running Task Scheduler
  • Restoring backed-up system files
  • Viewing or changing another user’s folders and files
  • Repairing a network connection (requesting a new IP address)

Common tasks, such as changing the time zone, do not require administrator privileges[6] (although changing the time itself does, since that is a global setting). A number of tasks that required administrator privileges in earlier versions of Windows, such as installing critical Windows updates, no longer do so in Vista.[7]

Features

User Account Control asks for credentials in a Secure Desktop mode, where the entire screen is temporarily darkened and only the authorization window is enlightened, to present only the elevation UI. This is to prevent spoofing of the UI or the mouse by the application requesting elevation.[8] If an administrative activity comes from a minimized application, the secure desktop request will also be minimized so as to prevent the focus from being lost. It is possible to disable Secure Desktop, though this is inadvisable from a security perspective.[9]

Applications written with the assumption that the user will be running with administrator privileges experienced problems in earlier versions of Windows when run from limited user accounts, often because they attempted to write to machine-wide or system directories (such as Program Files) or registry keys (notably HKLM)[3] UAC attempts to alleviate this using File and Registry Virtualization, which redirects writes (and subsequent reads) to a per-user location within the user’s profile. For example, if an application attempts to write to “C:\program files\appname\settings.ini” and the user doesn’t have permissions to write to that directory, the write will get redirected to “C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\.”

There are a number of configurable UAC settings. It is possible to:[10]

  • Require administrators to re-enter their password for heightened security
  • Require the user to press Ctrl+Alt+Del as part of the authentication process for heightened security
  • Disable Admin Approval Mode (UAC prompts for administrators) entirely

Command prompt windows that are running elevated will prefix the title of the window with the word "Administrator", so that a user can discern which command prompts are running with elevated privileges.[11]

Internet Explorer 7's "Protected Mode" feature uses UAC to run with a 'low' integrity level (a Standard user token has an integrity level of 'medium'; an elevated (Administrator) token has an integrity level of 'high'). As such, it effectively runs in a sandbox, unable to write to most of the system (apart from the Temporary Internet Files folder) without elevating via UAC.[4][12] Since toolbars and ActiveX controls run within the Internet Explorer process, they will run with low privileges as well, and will be severely limited in what damage they can do to the system.[13]

Configuration

UAC can be configured via security settings (secpol.msc). All configuration items are prefixed with “User Account Control”. The following settings allow you to control UAC:

  • Behaviour of the elevation prompt for administrators in admin approval mode.
    • Turn off UAC (no prompt).
    • Prompt for consent (default).
    • Prompt for credentials.
  • Behaviour of the elevation prompt for standard users.
    This settings determines what happens if you run as a standard user and start a program that needs administrator rights (for the cases UAC can determine admin rights are required e.g. does not work for MMC snapins).
    • No prompt: fail and do not start the program if it required admin rights.
    • Prompt for credentials (default).
  • Admin approval mode for the built-in administrator account.
    This setting can be used to disable UAC for the built-in Administrator account (however, this account is disabled by default in Windows Vista).
    • Enable (default)
    • Disable
  • Detect application installations and prompt for elevation.
    Windows by default uses some heuristics to determine if an EXE is an installer (which most likely requires elevation)
    • Enable (default)
    • Disable
  • Switch to the secure desktop when prompting for elevation.
    • Enable (default)
    • Disable
  • Only execute executables that are signed and validated.
    If enabled an additional check is done after the elevation prompt. If the EXE is not signed the EXE will not be started.
    • Enable
    • Disable (default)
  • Virtualize file and registry write failures to per-user locations
    • Enable (default)
    • Disable
  • Run all administrators in Admin Approval Mode.
    To switch off UAC set this setting to disabled and reboot. All UAC behavior will be disabled, including file and registry virtualization.
    • Enable (default)
    • Disable

Requesting elevation

A program can request elevation in a number of different ways. One way for program developers is to add a requestedPrivileges section to an XML document, known as the manifest, that is then embedded into the application. A manifest can specify dependencies, visual styles, and now the appropriate security context:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <v3:trustInfo xmlns:v3="urn:schemas-microsoft-com:asm.v3">
    <v3:security>
      <v3:requestedPrivileges>
        <v3:requestedExecutionLevel level="highestAvailable" />
      </v3:requestedPrivileges>
    </v3:security>
  </v3:trustInfo>
</assembly>

Setting the level attribute for requestedExecutionLevel to "asInvoker" will make the application run with the token that started it, "highestAvailable" will present a UAC prompt for administrators and run with the usual reduced privileges for standard users, and "requireAdministrator" will require elevation.[14] In both highestAvailiable and requireAdministrator modes, failure to provide confirmation results in the program not being launched.

A new process with elevated privileges can be spawned from within a .NET application using the "runas" verb. An example using C++/CLI:

System::Diagnostics::Process^ proc = gcnew System::Diagnostics::Process();
proc->StartInfo->FileName = "C:\\Windows\\system32\\notepad.exe";
proc->StartInfo->Verb = "runas"; // Elevate the application
proc->Start();

In a native Win32 application the same "runas" verb can be added to a ShellExecute() or ShellExecuteEx() call.[4]

  ShellExecute(0, "runas", "C:\\Windows\\Notepad.exe", 0, 0, SW_SHOWNORMAL);

In the absence of a specific directive stating what privileges the application requests, UAC will apply heuristics to determine whether or not the application needs administrator privileges. For example, if UAC detects that the application is a setup program, in the absence of a manifest it will assume that the application needs administrator privileges.[15]

Criticism

There have been complaints that UAC notifications slow down various tasks on the computer such as the initial installation of software onto Windows Vista.[16] It is possible to turn off UAC while installing software, and reenable it at a later time.[17] However, this is not recommended, since as File & Registry Virtualization is only 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.[18] Also note that Internet Explorer 7's "Protected Mode", whereby the browser runs in a sandbox with lower privileges than the standard user, relies on UAC; and will not function if UAC is disabled.[12]

Yankee Group analyst Andrew Jaquith stated that "while the new security system shows promise, it is far too chatty and annoying."[19] However, this statement was made over six months before Vista was actually released (even before Beta 2 was released). 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.[3]

See also

References

  1. ^ "The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)". The Windows Vista and Windows Server 2008 Developer Story Series. Microsoft. April 2007. Retrieved 2007-10-08.
  2. ^ "Understanding and Working in Protected Mode Internet Explorer". Microsoft. January 2006. Retrieved 2007-12-08. Unknown parameter |coauthors= ignored (|author= suggested) (help)
  3. ^ a b c Torre, Charles (March 5 2007). "UAC - What. How. Why" (video). Retrieved 2007-12-08. Check date values in: |date= (help) Cite error: The named reference "Channel 9" was defined multiple times with different content (see the help page).
  4. ^ a b c Kerr, Kenny (September 29 2006). "Windows Vista for Developers – Part 4 – User Account Control". Retrieved 2007-03-15. Check date values in: |date= (help)
  5. ^ Bott, Ed (2007-02-02). "What triggers User Account Control prompts?".
  6. ^ Allchin, Jim (2007-01-23). "Security Features vs. Convenience". Windows Vista Team Blog. Microsoft. Retrieved 2007-03-04.
  7. ^ "User Account Control Overview". Technet. Unknown parameter |Publisher= ignored (|publisher= suggested) (help)
  8. ^ "User Account Control Prompts on the Secure Desktop". UACBlog. MSDN Blogs. 2006-05-03. Retrieved 2007-02-25.
  9. ^ Bott, Ed (February 2 2007). "Why you need to be discriminating with those Vista tips". Ed Bott's Windows Expertise. Retrieved 2007-12-08. Check date values in: |date= (help)
  10. ^ "Chapter 2: Defend Against Malware". Windows Vista Security Guide. Microsoft. November 8 2006. Retrieved 2007-03-15. Check date values in: |date= (help)
  11. ^ "Administrator Marking for Command Prompt". UACBlog. MSDN Blogs. August 1 2006. Retrieved 2006-08-07. Check date values in: |date= (help)
  12. ^ a b Russinovich, Mark (June 2007). "Inside Windows Vista User Account Control". TechNet Magazine. Microsoft. Retrieved 2007-12-08.
  13. ^ Friedman, Mike. "Protected Mode in Vista IE7". IEBlog.
  14. ^ Mike Carlisle (2007-03-10). "Making Your Application UAC Aware". The Code Project. Retrieved 2007-03-15.
  15. ^ "Understanding and Configuring User Account Control in Windows Vista". Microsoft. Retrieved 2007-07-05.
  16. ^ "Disabling the UAC feature". 2007-03-10. Retrieved 2007-03-10.
  17. ^ "Windows Vista upgrade power tips".
  18. ^ Bott, Ed (2007-02-02). "Why you need to be discriminating with those Vista tips". Ed Bott's Windows Expertise. Retrieved 2007-07-05.
  19. ^ Evers, Joris (2006-05-07). "Report: Vista to hit anti-spyware, firewall markets". ZDNet News. CNet. Retrieved 2007-01-21.

External links