User Account Control (UAC) is a new technology introduced by Microsoft in Windows Vista and most of the time it is misunderstood by users and developers. It's main purpose is to protect the operating system by running applications with reduced privileges.
Why should we use this? Most applications DO NOT require full privileges. Think to the applications you have written and ask yourself if most of the job can be done without full writes (if you write to disk think if you could write in the user's folder or an isolated storage, if writing in registry to HKLM think if you could write to HKLU, etc). The answer is mostly sure "Yes".
So why run applications with full privileges when they can be run with limited? Running with more privileges than required is just a security vulnerability - If an attacker exploits a vulnerability in your application he will gain more control.
There are two mistakes developers tend to do:
- Request the end-user to run an application with full rights even though this is not necessarily (most of the time because of bad design practices)
- Do not request to user to run the application elevated but try to perform operations that require more rights
By design UAC can only elevate code at process level and only at process' startup (means that a running process cannot be elevated). In the .NET world this also means that you cannot elevate code running in another app domain because the app domain is part of a running process. In order to elevate an existing application this must be closed and reopen with more privileges.
There are two types on UAC dialogs: blue and yellow. When you see a blue dialog you can be sure that the application requesting privileges is signed and trusted. The yellow dialog shows for any application that is not digitally signed and is not fully trusted.
User Account Control also prevents a lower privilege process to do the following (list below taken from MSDN):
- Perform a window handle validation of higher process privilege.
- SendMessage or PostMessage to higher privilege application windows. These Application Programming Interfaces (APIs) return success but silently drop the window message.
- Use thread hooks to attach to a higher privilege process.
- Use Journal hooks to monitor a higher privilege process.
- Perform DLL injection to a higher privilege process.
Let's see how an UAC aware application should look.It should be composed of two executables (one that will be run with limited privileges and another one that will be started only with needed and with full rights) or two working modes (a mode for limited rights and another one for full rights). Either way you must remember that once you elevated the application and finalized the administrative tasks, the process should be destroyed in order to reduce an attacker's privileges.
In order to launch an elevated process in Windows Vista the process must be started with the "runas" verb. The Verb property is part of System.Diagnostics.Process.StartInfo class. The code snippet that launches "notepad.exe" with full rights is showed below:
If you choose to have only one executable file that acts differently based on permissions you should check if the user is part of the administrative group. In Vista even if your user is part of the Administrators group it runs with reduced privileges by default and gains his full rights on demand. The code below stores true in the hasAdministrativeRight boolean variable if the user's privileges are administrative and false otherwise.
To elevate the current application you must create a process with elevated rights and close the existing instance. However you cannot start a process with limited privileges - I couldn't find a solution. Anyone knows how to start a less privilege process from a higher privilege one? The sample creates an elevated instance of the current executable and closes the existing one.
RunElevated is a method that takes the name of an executable and spawns it in a new elevated process (see the attached code).
I have created a sample application that illustrates all the things written so far: it displays the user's rights, elevates the current application and starts a process with more privileges. In order to see all features of the application you must have UAC enabled. You can download the code from this link.
Please note that here I recommend to run applications with limited privileges but there are situations when applications need to run unrestricted - this is the case of system configuration utilities or other special applications. What I want to say is that you should run applications in an unprivileged environment when possible.
This is part one of the tutorial. Part 2 will explain how to use the manifest file to specify that an executable must be always run with full privleges.