ARTICLES IN THE BOOK
A GUIDE TO WINDOWS VISTA
This article is from:
All text is available under the terms of the GNU Free Documentation License: http://en.wikipedia.org/wiki/Wikipedia:Text_of_the_GNU_Free_Documentation_License
User Account Control (UAC) is a technology and security infrastructure introduced with Microsoft's Windows Vista operating system. It aims to improve the experience of using Windows as a standard user.
Before Windows XP was released, previous versions of Windows targeted at the consumer audience, such as Windows 95, 98 and ME, were all operating systems where the user had super user rights despite multi-user capabilities. Windows XP on the other hand was 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.
Unfortunately, most legacy applications and even new applications were or are not designed to work without full administrator privileges. 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.
With Windows Vista, 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, no password is needed; instead, a dialog is shown with the choices to allow or deny the action.
When logging into Windows 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 however, 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 elevation or is run as administrator UAC will prompt for confirmation and, if consent is given, start the process using the unrestricted token.
User Account Control asks for credentials in a Secure Desktop mode, where the entire screen is blacked out and temporarily disabled 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. 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.
In Windows Vista, common tasks, such as changing the time zone, do not require administrator privileges. UAC also provides file and registry virtualization to allow poorly designed applications to run as a standard user.
Additionally, command prompt windows that are running elevated will prefix the title of the window with the word "Administrator", so that a user may discern which command prompts are running with elevated privileges.
There are a number of configurable UAC settings. It is possible to:
It has been accepted that having UAC enabled at all times can help secure the operating system, especially when browsing web sites that may pose a potential security threat, however there have been complaints that UAC notifications slow down various tasks on the computer such as the initial installation of software onto Windows Vista. It is therefore possible to turn off this feature whilst installing risk free software and preferably not being connected to the internet and then re enabling UAC afterwards.
A program can request elevation in a number of different ways. One way 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.
To spawn a new process with elevated privileges from within a .NET application you can use 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() call.
::ShellExecute(0, "runas", "C:\\Windows\\Notepad.exe", 0, 0, SW_SHOWNORMAL);