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:
ProcessStartInfo processInfo = new ProcessStartInfo(); processInfo.Verb = "runas"; processInfo.FileName = "notepad.exe"; Process.Start(processInfo); |
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.
WindowsPrincipal pricipal = new WindowsPrincipal(WindowsIdentity.GetCurrent()); bool hasAdministrativeRight = pricipal.IsInRole(WindowsBuiltInRole.Administrator); |
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(Application.ExecutablePath); this.Close(); |
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.
Have a look on UAC on Windows 7 (beta build 7000) : http://tinyurl.com/df4tpe ,http://tinyurl.com/d8rdcr
Cool, i didn’t know that’s possible from C#
Good job!
[...] Recent Comments April Fool’s Day – Live Search | Ex nihilo nihil fit on Chuck Norris LHC FactsApril Fool’s Day – Live Search | Ex nihilo nihil fit on Chuck Norris Java factsTimotei Dolean on Using UAC with C# – Part 1 [...]
Did you try to do it with a different user? I strugle with this for a days. It just does not elevate user rights.
Code Example:
…
ProcessStartInfo processInfo = new ProcessStartInfo();
SecureString securePassword = new SecureString();
foreach (char ch in “testpass”)
{
securePassword.AppendChar(ch);
} // foreach
processInfo.UserName = “testuser”;
processInfo.Password = securePassword;
processInfo.Verb = “runas”;
processInfo.FileName = @”c:\windows\system32\cmd.exe”;
processInfo.UseShellExecute = false;
Process.Start(processInfo);
…
testuser is administrator. Problem is that this code does not run process elevated. Do you have any idea? Thanks!
I think you should set processInfo.UseShellExecute to true and processInfo.Verb to “runas”
We already set .Vert to “runas”. You can not set UserShellExecute to true because than you can not impersonate another user. You will get appropriate exception if you try to do that.
Thanks for suggestion, but we are still looking to resolve it, since this is currently show stopper for our project.
Why are you specifying a username?
If an application needs to run as Administrator, leave off the Username and Password. If the user executing the application has rights to elevate, they will receive a UAC prompting them for this. If they do not, they will be prompted for the password of an account with elevate privilege by the UAC subsystem.
Doing this means your spawned process will run as the local Administrator user. This is most often what you want if you need administrator privileges.
In Vista/Win7, making an account “administrator” does not give it privileges on the system, rather it gives it an “elevate” privilege, meaning that account can approve a process to elevate itself to run as Administrator via the UAC dialogs. (Users not marked as Administrator need to supply the password for an Administrator account in order to elevate; users marked as Administrator need only click “OK” or Cancel as desired.)
Hope this helps
FM
We have to set username because we wanted to use impersonation of a user that did not start original process. Our tool have to behave like ‘runas’ command but without prompting for credentials.
In the meantime we contacted Microsoft support and in cooperation with their experts we clarify UAC.
You may read a post in our lab at http://www.icodefactory.com/lab
Thanks for the sample code, this helped me a lot.
Found this useful. Thanks for sharing.
Thanks, from Russia with love… =)