Using UAC with C# – Part 2
In part 1 of this tutorial I have presented how to run an application with and without elevation by specifying this from another process.
However there are some situations when an application cannot be run without administrative rights. For example a system configuration utility requires administrative rights to change some global policies.
In order to force an application to run only if the current user is administrator or can provide administrative credentials you must add a manifest to the C# project.
The manifest is an XML file named <application_name>.exe.manifest with the following content:
< ?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyidentity version="1.0.0.0" processorArchitecture="X86" name="UACApp" type="win32"/> <trustinfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedprivileges> <requestedexecutionlevel level="requireAdministrator"/> </requestedprivileges> </security> </trustinfo> </assembly> |
What is important is the requestedExecutionLevel element. It specifies what permissions (execution level) the application needs in order to start. If the current user does not have the required level then an elevation window is displayed (see part one of the tutorial that describes the elevation window).
The default value of requestedExecutionLevel if it is not specified in the manifest or the manifest does not exist is asInvoker. Except asInvoker and requireAdministrator there is another execution level. All three are described below:
| Value | Description | Comment |
| asInvoker | The application runs with the same access token as the parent process. | Recommended for standard user applications. Do refractoring with internal elevation points, as per the guidance provided earlier in this document. |
| highestAvailable | The application runs with the highest privileges the current user can obtain. | Recommended for mixed-mode applications. Plan to refractor the application in a future release. |
| requireAdministrator | The application runs only for administrators and requires that the application be launched with the full access token of an administrator. | Recommended for administrator only applications. Internal elevation points are not needed. The application is already running elevated. |
In order to embed the manifest in the aplication’s executable you can choose one of the following options:
Using UAC with C# – Part 1
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.
Vista Experience Index Fail
The left image is from the virtual machine and the one on the right from the laptop that runs the virtual machine.
As you can see the HDD from the virtual machine is faster than the one on which the VM is running. How is this possible? :-|
No more Y! Messenger for Vista
A few days ago Yahoo! posted a message announcing that Messenger for Windows Vista will no longer be available.
For those of you who don’t know this version a screenshot of it inside this post. It was a fancy looking application developed with WPF (Windows Presentation Foundation). It had a lot of transparencies, animations and colors but, in my opinion, was too slow (can’t say if this was because of WPF or because of the programming team).
Yahoo! said that the decision of renouncing to the Vista dedicated version will help them focus on the existing versions and improve them (I’m quite skeptic about this). It is known that Yahoo! Messenger is one of the worst applications if judged from performances point of view. Even the current version 9 is slow and it takes ~30 seconds to start.
On the first run, the Beta version of Yahoo! Messenger for Vista made everyone do “WOW!” but on a closer analysis its lack of features became annoying. There was no archive, no environments, no audibles and a lot of well-known features from the classic version. I think that this version was released to early and this lead to its extinction.
I’ve read on the Messenger official blog that some people are requesting the source code of the obsolete version :) It would be interesting to see the code because then we could say if the application was slow because of Yahoo! programmers or WPF.
The official “Yahoo! Messenger for Vista version is no longer available” announcement can be read here.