If you've used Vista, you've probably been exposed to the UAC dialog.  It's the security dialog that pops up when the screen goes gray, and asks you permission to perform a task which requires admin-level elevation.  The idea behind it is that once programs are written for Vista (with UAC in mind), they'll sort themselves into two categories:  Trusted programs that require administrative privileges (and have to pass a UAC prompt) to do their jobs, and programs that run fine without administrative privileges.

The big problem with rolling out UAC is how to deal with all of the legacy applications that have to still work.  I roughly divide legacy (pre-Vista) programs into five six categories:

  1. Programs that don't need or request admin privileges.

The majority of programs that run don't try to do anything forbidden like writing to system directories or opening .  These programs will run fine under Vista.

  1. Programs that don't need admin privileges, but try to access protected areas.

Even a well-intentioned app might open a system registry key for full access when it only reads the key, or might write its settings to a config file in the program files directory, because that was perfectly OK under XP where everybody ran as Administrator.  For these apps that didn't really need admin access, the system virtualizes these accesses.  A virtualized program is allowed to read and write as if they're writing to the system, but those changes are virtualized under the user's AppData folder.

  1. Utilities that legitimately need to be able to modify the system.

Some programs are fully intended to administer the system, and cannot run properly in restricted user mode.  Simply double-clicking this utility will cause it to fail, because the system doesn't know that it needs elevation.  These legacy programs must be launched with elevated privileges in order to work.  The three common ways to do this are to right-click the .exe and select "Run as Administrator", to select "Run as Administrator" in the compatibility tab of the program's properties dialog, or to run cmd.exe as administrator and launch from there.  Any of these methods will get you a UAC prompt, of course.  Fortunately most people don't need to run programs in this category very often.

Though many in the blogosphere would be quick to disagree, I'm actually glad that the UAC dialog is showing up here.  The dialog serves two purposes for me.  It is a warning flag whenever something is about to get access to my system's tender bits.  It is also a reminder that whenever it isn't there,  the OS is making certain that whatever's running can't get at my system's tender bits. 

  1. Malware

Some programs we just don't want to allow admin privileges to.  This is the class of programs for which UAC was invented.

  1. Installers

An installer is a special case of one of the previous categories which often needs more privileges than the program it installs.  This is because installers have to set up directories, resources, and registry keys.  Though it is possible to create an installer which does not need admin privileges, most legacy installers do need them and will fail without elevation, resulting in a bad user experience.  The Vista planners recognized this, and made installers a special-case.  Because most legacy installers will fail if they are not run elevated, Windows Vista will automatically elevate the privilege of any legacy installer.(after raising a UAC dialog, of course)

Eventually, application designers will write more Vista-aware programs,  which understand how to work around the different privilege levels.  A Vista-aware program can contain a manifest, which contains metadata on the program including whether or not it needs elevation.  Because unnecessary UAC dialogs annoy users, software vendors will work to avoid them.  In the ideal application world, then, the following happens with our five categories.

  1. Programs that run fine without elevation continue to run unchanged.  They were already doing the right thing.
  2. Programs that don't need elevation but try to access protected areas will be fixed so that they fit into category #1.  The registry access will be changed from full access to read-only, and the config file will be properly stored in the user profile's AppData directory.
  3. Legitimate Windows utilities include a manifest with the elevation bit set.  When you try to launch the program, Windows shows a UAC dialog.  The program is legitimate, and you intended to administer the box, so you click yes and the program runs with admin privileges.
  4. Malware in the post-Vista world will likely include a manifest with the elevation bit (because malware that doesn't is already blocked from affecting  the system).  Windows shows a UAC dialog, but you didn't intend to administer the system and you don't trust the source of the program, so you click no.
  5. Installers include a manifest.  The few installers which legitimately need to write to system locations (drivers, system utilities, debuggers) set the manifest's elevation bit.  Other installers leave the bit clear, and install without a UAC prompt.

Ideally, when the only programs that legitimately require elevation are system utilities and driver installers, the user will see very few UAC dialogs, and will be vigilant for malware whenever it rears its ugly head.  What a wonderful world it will be, then.  :-) 

 

  1. Programs that explicitly check for a version of the OS.

Some programs would run just fine on the OS, except that they bind to one specific version to the exclusion of later versions.  You may have seen this one, which pops up a dialog in setup on Vista saying "You must run this program on Windows XP".  The program checks GetWindowsVersion equal to XP, rather than checking that it's greater or equal.  For these buggy programs, there's Compatibility Mode.  When you run a program in Compatibilty Mode for a given version of Windows, Vista will lie to the program and pretend to be that version, causing it to run correctly.  To turn on Compatibility mode for a program, right-click the program and select Properties.  In the Compatibility tab, select "Run in compatibility mode".


Next time: See if you can spot the social engineering hole in this model.

 

UPDATE: It seems I mixed up virtualization with compatibility mode.  Fixed above (#2 and #6)