Windows Vista's Least-privilege User Account (LUA) (Page 2)
By: Arie Slob
Microsoft is proposing the following direction/solutions in Windows Vista. But first I want you to familiarize yourself with some of the terminology used. Also keep in mind that the names Microsoft uses today may change before Windows Vista ships. You will see both LUA (Least-privilege User Account) and UAP (User Account Protection) used with respect to Vista's account features.
Users in Windows Vista will now fall into the following groups:
- Standard User - A user that can run most software installed on the system, but that will have to ask a "Protected Admin" (PA) to elevate to run certain tasks.
- Protected Administrator - PA. A user that can self-elevate to run certain tasks.
- Administrator - Built-in administrator account on the machine. This account does not require elevation.
In this context, "elevation" is the act of giving/receiving consent to perform certain tasks.
Standard User
As you'll probably realize by reading the first part of the article, the single biggest problem would be in the way 3rd party applications are being written for Windows. For a time Microsoft tried to convince software developers to design their applications in such a way that a Standard User would be able to install/run those applications (as required for the "Windows Logo Program"), but developers are a stubborn group of people if you try to change their ways!
At some point, Microsoft figured it had to provide a technical 'fix' for this. Microsoft decided to use "Virtualization". Virtualization mimics part of the System & Registry to a user-based storage, and 'fools' legacy applications that require access to some file system areas or registry keys that they would not have access to on the system. The fancy name Microsoft gave this (for now): AIM (Application Impact Management).
Since installing applications will require administrative privileges in a lot of cases, Microsoft has built a mechanism into Vista that will detect the launch of an installer or setup program, and prompt the user for administrative credentials to approve the installation. When the application is installed, running it will run as limited user.
This is a nifty technology. It will probably not work for a small group of applications that require real access to certain file system areas or registry keys. Microsoft is encouraging its beta testers to test as many applications as possible for LUA, to try and limit the number of applications that will not work with Vista's LUA when Windows Vista ships.
Protected Administrator (PA)
This is a new account type, and the intention here is that even an Administrator gets some protection. When you use the PA account, most of the applications you run will still only run in a restricted mode. For an application to run under full administrative privileges, it has to be "blessed". This can be done either by the PA, or through deployment tools at larger organizations.
So basically a PA is running as limited user; the difference is that a PA will be able to "self elevate"(Figure), while a standard LUA account will need a password from a PA account to elevate.
This is probably how the Windows XP "Power User" (now deprecated) should have been.
Administrator
The (built-in) Administrator account is basically the same as in Windows XP, has full administrative privileges, and does not require elevation.
Impact of LUA
Seen through the eyes of a system administrator who's responsible for a number of computers (work stations) throughout his organization (network), these changes will probably work pretty well. It will be easier to specify what users can & can't do on their machines, without crippling their ability to run everyday tasks.
From a home user perspective, I doubt there'll be a lot of impact here. First of all, I see most users will start running either as a PA or even full Administrator. Even when users run as PA, I can see that the potential for running rogue code still exists. If users get used to the fact that they are getting prompted for "elevation", it will become a routine, and users will just elevate without realizing exactly what they are doing. It also opens the door for spoofing the elevation request when users no longer pay much notice to these requests. And how long will it take for someone to write a piece of malware that finds a way to "bless" itself (meaning it can run with full admin rights without a prompt to the user)?
Additional Reading
Aaron Margosis' WebLog (Aaron is a Senior Consultant with Microsoft Consulting Services.)
Give your comments on this article.