Over the past several years, the security of operating systems has become more and more important. In response to the perception that their operating systems are less secure than their Linux based competition, Microsoft has responded by integrating a new security mechanism called User Access Control (UAC) into their newest operating system Vista. In this article I will describe what UAC is and how it works, why it is important to developers, and how you can ensure that your .NET applications are compliant with the new paradigm.

UAC is designed to address the problem of malware. Most users, whether they need to or not, log in as local an Administrator. As a result, any application that runs in their session has full Administrator access to the operating system. This includes malware.

In short, UAC requires the user to confirm the execution of any application that requires elevated permissions. By doing this, malware is essentially cut-off from even being able to start. If you do not know the application that is asking for elevated permissions, simply do not allow it to execute.

When a non Administrator logs into Windows Vista, they are granted a standard user token. All work that user does in Vista is down under the privileges granted by that token. If a non Administrator with only a standard user token attempts to perform an action that required elevated privileges, Vista will prompt them to enter Administrator credentials (user name and password). If elevated privileges are granted, a new token with Administrative privileges is created for that process. When the process ends the token is destroy. Tokens can be passed from parent processes to child processes, but beyond that there is no sharing of tokens among processes.

When an Administrator logs into Windows Vista, two tokens are created: a standard user token and an Administrator token. As with a non-Administrative user, the Administrator will generally operate with their standard user token. When the Administrator attempts to perform an action that required Administrative privileges, UAC prompts the user to allow the action. If the Administrator consents, a copy of the user Administrative token is created. The process requiring the elevated uses that copy to perform its functions. Like the previous example, once the process is complete the token is destroyed. Also, like the previous example, a parent may pass the token to a child process, but no other sharing of tokens between processes is allowed.

When developing applications for Vista, it is important to keep the concept of elevated privileges in mind during design. The list of tasks that require Administrator privileges is shorter that the list for Windows XP, and architects should be aware of this when they are building in features that require these privileges.

If your application does not require elevated privileges, there is nothing more that needs to be done. It is ready to be deployed to Vista. This should be the type of application that is generally developed and architects should strive to design the need to use Administrative tasks out of their applications. If your application is targeting Administrators, then you application needs to inform Vista that will need elevated privileges at launch. This is done via the assemblies manifest and is demonstrated below. Without the request for elevated privileges in the assembly, the first time the application attempts to perform an action that required elevated privileges an exception will be thrown.

If your application supports functionality that occasionally requires elevated privileges, it is recommended that those features be abstracted out to a separate executable that can be called from the main application. The executables that require elevated privileges must be signed.

While Visual Studio Orcas and the next version of the .NET Framework (3.5?) will include many of the new features available in Vista, most of us today are using Visual Studio 2005 for production. You can still use all the new features of Vista, including UAC, however, more manual steps are required on our part.

As I stated earlier in this article, for applications in Vista to be able to use feature and functionality that require elevated privileges, the application must inform at launch that they will be requiring those permissions. In this scenario assume you are creating an application called “HelloVista” as a standard .NET 2.0 Winforms application.

The first step is to create a resource file. This is done by right-clicking on your project and selected “Add New Item…” and selecting “text file” from the list. Rename this file ProjectName.rc where ProjectName is the name of the Visual Studio project you are creating the resource script for. Right click on this file and select “Open with…” and select the text editor from the list. Past in the following code.

Listing 1

#define APP_MANIFEST 1 
 #define RT_MANIFEST 24 
 
 APP_MANIFEST RT_MANIFEST ProjectName.exe.manifest

This code will cause the ProjectName.exe.manifest as a manifest resource in your assembly. If you are adding this manifest to an executable, APP_MANIFEST should be set to 1. If your assembly is going to be a DLL, then the value should be set to 2. Save this file.

The next step is to create the manifest file you just specified in your resource script. To do this right click your project and select “Add New Item…” and once again select “text file.” This time you are going to name it ProjectName.exe.manifest where ProjectName is again the name of your project. Open this file and insert the following code.

Listing 2

<?xml version="1.0" encoding="utf-8" ?> 
 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
   <assemblyIdentity version="1.0.0.0" 
       processorArchitecture="X86" 
       name="HelloVista" 
       type="win32" /> 
   <description>HelloVista</description> 
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
     <security> 
       <requestedPrivileges> 
         <requestedExecutionLevel level="requireAdministrator"  /> 
       </requestedPrivileges> 
     </security> 
   </trustInfo> 
 </assembly>

Notice the information in the security element. We are setting the requested execution level to “requireAdministrator” which tells Vista that the application required Administrator privileges to run. The alternative value we could use here is “asInvoker” which allows the process to run with the same access as the parent token, but with no access to “C:\”, “C:\Program Files” or the HKLM node in the registry. The other available value is “highestAvailable” which runs in the highest privileges available to the user. Save this file.

Visual Studio needs to know to compile your resource script into a resource file. This is accomplished by adding the following pre-build step to your projects properties.

Listing 3

"$(DevEnvDir)..\..\SDK\v2.0\bin\rc.exe" /r "$(ProjectDir)$(TargetName).rc"

The last step is one that might be a little scary; we need to hand-edit the Visual Studio project file.  Close Visual Studio and locate your csproj file. Open this in note pad. Find the first <PropertyGroup> tag and add the following line substituting the ResourceFile name with the name of the resource script you created in the first step.

Listing 4

<Win32Resource>ResourceFile.res</Win32Resource>

So your csproj should look something like the one shown below.

Listing 5

<PropertyGroup> 
   <Win32Resource>Project.res</Win32Resource> 
 </PropertyGroup>

Save and reload your project in Visual Studio. Build your application then navigate to the folder and execute your application. You should be asked to confirm the applications request to run with elevated privileges. Congratulations, you just wrote your first UAC compliant application!

This is a simple example, where you are creating a single executable. For an example of how to create an application with only specific libraries elevated, check the documentation for the Windows SDK.