.NET Wrapper for COM Elevation

Microsoft has ramped up the security in their latest operating system – Windows Vista, which means that developers now have to pay more attention to certain security constraints imposed by the operating system when developing applications.   Those of you readers who have read my prior posts on User Access Control in Vista (and the further reading article), may be interested in this small software project I put together. 

The Problem in a Nutshell

Vista requires that ALL users (even administrators) obtain an elevated security token before being permitted to execute protected API calls or accessing protected system resources (the registry for example).  In prior versions of Windows, system administrators were given a privileged security token at login and permitted to perform any task without further confirmation from the interactive user.  Windows Vista now allocates a low security token by default to all users and administrators, and an elevated token is only obtained with credentials (users) or confirmation (administrators) when required.

Elevation request is determined by Vista before any process is loaded – so if a particular process is running non-elevated then access to protected resources and APIs within that process is denied.  This is an important caveat, as it affects the way in which software developers approach application design.

How does one Elevate their Process?

There are several articles on the Internet about developing elevated processes in Vista, so I’ll not dwell on the steps here (my previous articles cover this subject), but essentially elevation request involves decorating .NET assemblies and WIN32 executables with elevation status in the application manifest file (may be embedded or side-by-side).

The COM Elevation Moniker is another method for obtaining elevation.  Using the CEM it is possible to host a COM (Component Object Model) component in elevated state using the dedicated system process – DLLHost.exe.  The Windows Vista SDK provides details on adding the necessary code to your project to elevate an out-of-proc component and making it available to your non-elevated application.

So why use the COM Elevation Moniker?

The CEM permits a non-elevated process to execute protected API calls and access protected resources by calling across process boundaries into an elevated process.  This is how Vista achieves mid-application elevation – look for the shield symbols in forms and property pages, to get an idea of what I am talking about. 

So what’s the big deal?

Development of a CEM component typically involves some work in C++.  Development of COM components in VB and .NET is of course possible, but when it comes down to accessing WIN32 calls to perform COM elevation most of the examples are published in C++.  Developing a managed CEM is possible but involves some work to get it operating correctly.

What about cross boundary communication? – This is the klutz of the problem with authoring CEM components, how to communicate across process boundaries?  COM development answered this problem a long time ago, and the same is true now as it was then – marshalling data and cross process communication is handled by the COM infrastructure.  But what about managed code?  If you’ve managed to solve the problem of invoking a .NET assembly as a COM CEM component, you still have to communicate over .NET interop, which may not be ideal.

Surely someone must have a way to perform elevation in the managed world?

The .NET Wrapper for COM Elevation

I wanted a way for managed developers to attribute their code classes in such away that embedded methods of these classes would request elevation from the Vista operating system before execution of such methods.  So I went about developing a library to encapsulate the complexities of the COM Elevation Moniker.  The end result is available to download from here.

After downloading the ZIP files and unpacking it, the library is packaged as an MSI installer file, which must be installed as an administrator to make use of the library functionality.  The installer also installs some example code to demonstrate use of the library.

How does the Managed Wrapper Library Work?

Essentially, the wrapper library exists as a managed and non-managed server.  The non-managed COM server provides the infrastructure to elevate managed code by hosting it’s own .NET AppDomain.  The managed server assembly is loaded into the elevated AppDomain and executes code developed by the end user of my library.

Communication between the hosted managed server and client code is achieved using an IPC (Inter-Process Communication) channel developed against WCF (Windows Communication Foundation).  The exact specifics of this set up is beyond the scope of this blog post, but involves the use of CodeDOM (dynamic code generation) to create a dynamic messaging system between elevated code and non-elevated client proxy. 

My wrapper library is very much “beta” at present.  I’ve published my library in the hope that I can attract a number of developers to use it and let me know their initial thoughts.  Documentation is sparse, but I am working on publishing a technical manual. It is important to understand that end-users of my library require no knowledge of WCF development, C++, or COM expertise, which makes my library versatile and easy to use by managed developers of different skill-level.

For now, I’ll end this post with a thank-you – for taking an interest in my project.  I look forward to receiving feedback (good and bad), especially any pertaining to security aspects.

16 thoughts on “.NET Wrapper for COM Elevation

  1. http://

    Does the COM dll have to be installed in the GAC? I have been trying to get it to run with out having to be installing in the GAC

  2. robgarrett

    Hi Terry,
    No the COM DLL is not to be installed in the GAC (only .NET assemblies install in the Global Assembly Cache). However, the managed component that derives from the Elevated Service class does need to be installed in the GAC so the elevation COM dll can find it with full trust.

  3. Lei Xu

    Hi Rob, this is exactly the knid of library I’m looking for. As a .NET developer and trying to work with Vista UAC in managed world, your library really helps (although I havent really use it yet). However, after reading a lot of C++ MSDN document about CEM and try to write something simliar …
    Well, here comes the questions, there are different elevation levels, highestAvailable, requireAdministrator; and different senarios, Admin process and over the shoulder elevation; how do you handle these? Are you only support requireAdministator right now? (maybe that’s enough though).

  4. http://

    hi Rob,

    i couldnt figure out how i could apply UAC on this particular code. This runs fine on XP but not on vista due to elevation error. Can you help me out on this? thank you πŸ™‚

    INetConnectionManager *pNetConnectionManager = NULL;
    hr = CoCreateInstance(CLSID_ConnectionManager,
    NULL,
    CLSCTX_LOCAL_SERVER | CLSCTX_NO_CODE_DOWNLOAD,
    IID_INetConnectionManager,
    reinterpret_cast<LPVOID *>(&pNetConnectionManager)
    );

  5. http://

    Hi,
    I am new to vista logo certification. I have one confusion in this regard.

    In my application, I already have icons and text on command buttons. My question is how can I display a shield icon on the command buttons of my application.

    Should I have to remove the already used icon and can only display shield Icon with text on command buttons of my application. OR I can embed shield icon on icons of my application along with text like overlay icon which is already used for application exe’s only.

    Kind regards,
    Touseef Afzal

  6. http://

    Thank you for great code. Is it possible to look at the source? If yes, please send it to kristin.mytinger[@]gmail.com
    Thank you very much!!!

  7. http://

    The source code is incomplete. Was unable to get this working or understand what is really going on inside the project.

    It might be possible to get this working if you post the full source. Also it requires .NET 3.5 which will still be restrictive for some who are targeting 2.0. The source is missing for the parts which target 3.5

  8. robgarrett

    I can send you the source, drop me an email via the contact form.
    Yes, you need at least .NET 3.0, this is because the code uses WCF to generate an on the fly service and proxy. This approach is not possible in .NET 2.0. If you’re using Vista (which of course you are if you’re looking at elevation), then you’ll have the .NET 3.0 framework installed.

Comments are closed.