Vista's user account control (UAC) lets applications elevate to administrator-level privileges, but there's a right way and a wrong way to do it. Processes can't change their permissions dynamically, so it's important to ask for elevated privileges correctly. The three basic approaches are to launch a new version of your process, to create an elevated COM object and to send requests to tasks and services that run in elevated administrator privilege, said Crispin Cowan, senior project manager at Microsoft's UAC team at a talk he gave at PDC in October.
This tip is part of a series on UAC based on Cowan's talk. If you haven't read our introduction to developing programs under UAC, you may want to start there. You may also want to read our tip on how to write installers that run in UAC.
1. Launch a new, elevated process
Programs can't be elevated once they've already been launched, so the simplest technique is to start your program in standard user and include a button that launches a new, privileged version of the process before closing the original version. You should mark the elevated program with "asAdministrator" in your program's manifest. This is the technique that the task manager uses when the user clicks on the "show processes from all users" button, for instance.
The advantage of this method is that it's easy, but there are two drawbacks. First, closing the first process and opening a new one in its place disrupts the user experience slightly; the window appears to close and open again. More importantly, programs can't un-elevate themselves, so the program will now be running in administrator mode until it exits, negating UAC's security improvements.
2. Create an elevated COM object
A slightly more sophisticated approach to elevating is to create a new COM object with elevated privileges. If you do this, make sure that object creates its own GUI, Cowin said. A common pitfall is to create an invis...
To continue reading for free, register below or login
To read more you must become a member of SearchWinDevelopment.com
ible, elevated COM object and send messages to it from your un-elevated GUI. But malware can hijack that GUI by faking mouse clicks and using the GUI to drive malicious messages to the COM object. If your COM object draws the GUI, Vista's user interface privilege isolation (UIPI) hides it from non-privileged software. Use CreateElevatedComObject to generate this elevated COM object.
3. Use tasks or services
The third way to handle elevated processes is to refactor them into tasks or services, background processes that your installer creates. Services work in any operating system and always run in the background, while tasks are created and destroyed as needed but only work for Vista (and Windows 7, when it comes out).
The advantage to tasks and services is that it creates a seamless user experience. The major disadvantage is that services and tasks can't create GUIs, so you have to send messages to them from an unprivileged GUI source -- the exact situation you tried to avoid with an elevated COM object.
If you take this approach, make sure to sanitize all inputs and treat them as suggestions, not commands, Cowin said. In other words, assume every message is coming from malware, and make sure to validate every argument. When you sanitize inputs, use an allow list rather than a deny list -- in other words, assume every character is bad and make exceptions for those you know are good, rather than trying to specifically block out characters you know are bad. "Anyone who's ever used a deny list has regretted it. Trust me," Cowin said.
Yuval Shavit is the associate editor for searchWinDevelopment.com. Email Yuval to tell him what you thought about these tips. These tips are based on a talk by Crispin Cowan, product manage for Vista's UAC team, which he gave at Microsoft PDC. The talk, "Windows 7: Best Practices for Developing Windows Standard User" is available online.
