Why User Account Control (UAC)?

re: Why User Account Protection (UAP)?

Mike Rickard — Tue, 18 Oct 2005 01:34:27 GMT

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)

re: Why User Account Protection (UAP)?

UAP — Tue, 18 Oct 2005 04:29:25 GMT

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!

Another security strategy - Using Least Privilege

.NET MVP KenLin's Blog — Tue, 14 Feb 2006 06:27:57 GMT

I recently read about Programming on Windows Authenication, I got a lto of result after searching. I...

Is your MSI Package ready for Vista?

Rob Mensching on Software Installation and Open Source at Microsoft. — Wed, 22 Feb 2006 21:34:03 GMT

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

Vista User Account Control, Seguran

Rui Quintino — Thu, 06 Apr 2006 03:36:08 GMT

Using RunAs in Windows XP

Slater in Seattle — Wed, 10 Jan 2007 08:52:51 GMT

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