Sunday, September 18, 2005

PDC: Vista LUA

One of the things I got to do at the PDC was attend a Vista compatibility testing session with someone from Microsoft. I had a number of features break in my application and they all centered around LUA. It was a very eye opening experience and definitely worth the time.

Least-privilege User Account (LUA) (sometimes known as User Account Protection or UAP) is a new feature in Vista that is intended to help prevent some of the issues we've seen in the past with Viruses/Spyware/malware taking advantage of users that run with administrator privileges.

Keep in mind that the information below was based on the build of Vista they had available at the PDC. I'm sure much of it is subject to change.

With LUA, any group membership permissions are stripped away and all the users on the system (except for the built in administrator account) run with standard user privileges. Instead of the group membership (i.e. administrators group) determining what your access privileges are, the group membership determines your "elevation potential".

For example, in order to perform an action that requires administrator privileges, like installing an application, Vista will prompt the user once per process (at the start) to elevate the privileges for that user. Whether Vista will prompt, prompt with request for credentials (i.e. password) or elevate silently is controlled by the security policy setting in: Local Security Settings->Local Policies->Security Options

Any programmatic queries to determine the user permissions will return the standard user token unless that user's permissions have already been elevated. We may see an API that can determine a user's elevation potential.

Access rights elevation, can only be performed when an application starts and will be based on heuristics (for backwards compatibility support) or an application manifest.

Application manifests allow an application to be marked with 1 of 3 LUA settings.
  • "Invoker", which is the default and simply gets the parent token.
  • "Highest" prompts for the highest permissions a particular user has. Apps that are marked with "highest" may have different behaviors based on the user's permissions. For example, regedit could still run without administrator rights but only provide read-only access to HKLM.
  • "Requires Admin" means that a particular application will only run if the user can be elevated to and accepts administrator rights.

If you have a scenario where your application does not usually require elevated access rights but certain functions within that app does (like update), you can launch a separate process that requires those rights. It's important to note that by default, an application will get the same privileges as the parent process.

For this reason, Microsoft is not recommending that you launch an application right after an installation is complete -- since the installer will need elevated privileges, the child process will also get them. They are considering a new API to allow a developer to launch a process with LUA.

For legacy applications (no LUA manifest entry) that require administrator rights the shell supports right-clicking on an application and choosing the "run elevated" menu item. This will prompt for elevation consent and run the application with elevated permissions.

MS indicated that if you work with them, legacy exe's can be marked by the OS as requiring elevated privileges. This is purely to preserve backwards compatibility.

For situations where you cannot right click on the application to run it, the add/remove programs uninstaller for example, you can take advantage of the fact that child processes get their security token from their parent process.

For the add/remove programs case, you can run the command prompt with elevated privileges and launch appwiz.cpl to bring up the add/remove programs wizard with the permissions you require.

Access to HKLM, and the program files directory when insufficient privileges are available do not fail but are virtualized on a per user basis. Exe, dll and other binary files are not virtualized.

I've seen my share of spyware on family and friends machines so I'm quite happy to hear about this feature, I think it will help a lot.

The things I worry about with LUA is that the prompts for elevated access rights will become annoying and/or that those prompts will lose their effectiveness when users start to blindly accept the elevation.

That said, anything that will help keep our machines more secure is a good thing. As Bill Gates stated in his PDC keynote, Vista is about confident, clear and connected experiences. LUA addresses the "confident"/safe part of that equation.


At 11:40 PM, Anonymous Anonymous said...

This article helped to gain basic info on LUA.
Thank you.


At 11:33 AM, Anonymous Anonymous said...

Thanks for explaining all this! It really helped me out :)


Post a Comment

<< Home