Joshua's Blog now with actual content!

While I was working on one of my personal projects I needed to do some administrative tasks from a program launched as a normal user. Since I try to follow best practice to the best of my ability I knew I had to write an external module that could elevate to handle the administrative tasks required.

After doing quite a bit of research I came across two possible methods

1. Create a new external program with <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> in the embedded manifest and pass all of the information needed through the command line.
2. Create a COM object and elevate the object when using it. Information would be passed through COM object calls in real time and allows the caller to handle problems.

Obviously because I like a challenge and I'm a sadist, I decided on option number two, creating and elevating a COM object. Following the directions generously provided by Christoph Wille I was able to successfully create and register a .Net COM object that was able to be elevated. Unfortunately after elevating the object I was unable to invoke any methods and kept getting an odd exception (I think it was 0x80070005, Access Denied, I didn't keep notes for it – so it may be I'm mixing them up).

Honestly, I didn't get the .Net method 100% working, no matter how I ran the commands the methods with the [ComRegisterFunction] and [ComUnregisterFunction] never executed, so I had to finish registration by hand (without those extra registry entries, the COM object won't elevate). As part of my troubleshooting and because of the actions I needed to take when elevated I switched from a .Net component to an ATL component. This simplified development since I could incorporate the registry entries directly into the .rgu file.

Thinking I've solved all of the problems I wrote the ATL COM component, coded it to the best of my ability, set up the .Net calling code and tried it out. Guess what... 0x80070005 Access Denied. At this point I was going insane, everything I tried and everything I did was being denied when it was elevated. If I launched the object under the normal user I was able to interact with it. Elevate it? BOOM access denied. *sigh*

Continuing to research and try to find the problem, I eventually read the small nugget of information about Over-The-Shoulder elevation. Having been on this page many, many times trying to find the information I need, I felt quite stupid when I realized the information I needed was right there the whole time.

For such servers, COM computes a security descriptor that allows only SELF, SYSTEM, and Builtin\Administrators to makes COM calls into the server. This arrangement will not work in OTS scenarios. Instead, the server must call CoInitializeSecurity, either explicitly or implicitly, and specify an ACL that includes the INTERACTIVE group SID and SYSTEM.

Totally makes sense right? Well, to break it down simpler, the default security on the COM object is such that only SYSTEM and Administrators have access to the COM object when elevated, and even though you just gave it permission, your limited user process can't access it. Turns out to properly allow a limited process access to the elevated COM object you need to grant Local Activation to the INTERACTIVE SID.

After using the Component Services snap-in (dcomcnfg) and manually granting the right permissions and confirming that it worked I looked for a way to make the change programmatically, and what do you know, there's an example right there on that same MSDN article!

Below is the code I use to set up the proper security for the COM object (grants local activation to INTERACTIVE and SYSTEM, grants local and remote activation to the Built-in Administrators and SELF SIDS) and is executed through the DllRegisterServer function that ATL calls when registration is to occur. The registry entries required for elevation are handled by ATL when it processes the .rgu file.

STDAPI DllRegisterServer(void) {
  // (0x3 = Local Access, 0x7 = Local + Remote Access)
  // See http://msdn.microsoft.com/en-us/library/ms693364(VS.85).aspx
  static const wchar_t comSDDL[] =
      L"O:BAG:BAD:(A;;0x3;;;IU)(A;;0x3;;;SY)(A;;0x7;;;BA)(A;;0x7;;;PS)";
  bool perUser = false;
  ULONG securityDescriptorSize = 0;
  SECURITY_DESCRIPTOR* securityDescriptor = NULL;

  // Determine if the registration is per user.
  ATL::AtlGetPerUserRegistration(&perUser);

  // registers object, typelib and all interfaces in typelib
  HRESULT hr = _AtlModule.DllRegisterServer();

  // Only set up the elevation moniker if it is a system-wide install.
  // (Elevation doesn't work on per-user COM)
  if (SUCCEEDED(hr) && !perUser) {
    hr = E_FAIL;
    if (!ConvertStringSecurityDescriptorToSecurityDescriptorW(comSDDL, SDDL_REVISION_1, (PSECURITY_DESCRIPTOR*)&securityDescriptor, &securityDescriptorSize))
      return E_FAIL;

    ATL::CRegKey rootAppId;
    ATL::CRegKey appId;
    if (ERROR_SUCCESS == rootAppId.Open(HKEY_CLASSES_ROOT, L"AppID", KEY_READ | KEY_WOW64_32KEY) &&
        ERROR_SUCCESS == appId.Open(rootAppId, _AtlModule.GetAppIdT(), KEY_WRITE | KEY_WOW64_32KEY) &&
        ERROR_SUCCESS == appId.SetBinaryValue(L"AccessPermission", securityDescriptor, securityDescriptorSize)) {

        hr = S_OK;
    }
    LocalFree(securityDescriptor);
  }
  return hr;
}