Elevating During Runtime

• Download executable - 9.4 KB
• Download source code - 10.1 KB

Background

Some actions and tasks require elevation to Admin rights. The User Access Control mechanism (UAC) provides the protection required to prevent performing critical changes by users other than the ones with Admin privileges. For example, if your application needs to make a change in the Registry, it will require Admin users to run it.

What happens if your application would not require Admin rights except for certain occasions, i.e., during first run only. In such case, you might prefer building your application with no specific requirement to be run in Admin mode, but when it needs to make a Registry change, only then, it will elevate itself to Admin mode.

Here is how that is done.

What is UAC

User Account Control (UAC) is a mechanism developed by Microsoft as part of the newer Windows versions (starting of Vista). It provides higher security level by limiting applications from performing sensitive and dangerous tasks without gaining administrative rights.

Is It Really Possible to Elevate During Runtime?

Well, not exactly. The entire idea behind UAC is to prevent users with limited access rights to perform tasks that require higher access rights, so when an application is executed in "user" mode, it can't change itself, as if it was initially ran in "Admin" mode. The trick is to be able to elevate itself during runtime, when required, by restarting it, elevated to "admin" this time.

Am I Running in Admin Mode?

This is the first question you should ask when you need to do something that requires administrative privileges. If your application was already started in "admin" rights, there is no need to elevate. Only when a certain task you are about to perform, requires "admin" rights, and your application was started in "user" mode, you need to elevate. So to begin with, how can you determine if your application is run elevated already.

First, you allocate and initialize a SID of the Admin group. According to MSDN, A security identifier (SID) is a unique value of variable length that is used to identify a security principal or security group in Windows operating systems. Well-known SIDs are a group of SIDs that identify generic users or generic groups. Their values remain constant across all operating systems.

Before we proceed, let's get familiar with another function, CheckTokenMembership.

The CheckTokenMembership function determines whether a specified security identifier (SID) is enabled in an access token. In order to determine group membership for tokens of applications, CheckTokenMembershipEx is used instead.

For our purpose, we can call CheckTokenMembership and by doing so, enquire whether the SID is enabled in the primary access token of the process.

To sum the first part, here is how we check if our application is running with administrative privileges:

//
BOOL IsAppRunningAsAdminMode()
{
    BOOL fIsRunAsAdmin = FALSE;
    DWORD dwError = ERROR_SUCCESS;
    PSID pAdministratorsGroup = NULL;

    // Allocate and initialize a SID of the administrators group.
    SID_IDENTIFIER_AUTHORITY NtAuthority = SECURITY_NT_AUTHORITY;
    if (!AllocateAndInitializeSid(
        &NtAuthority, 
        2, 
        SECURITY_BUILTIN_DOMAIN_RID, 
        DOMAIN_ALIAS_RID_ADMINS, 
        0, 0, 0, 0, 0, 0, 
        &pAdministratorsGroup))
    {
        dwError = GetLastError();
        goto Cleanup;
    }

    // Determine whether the SID of administrators group is enabled in 
    // the primary access token of the process.
    if (!CheckTokenMembership(NULL, pAdministratorsGroup, &fIsRunAsAdmin))
    {
        dwError = GetLastError();
        goto Cleanup;
    }

Cleanup:
    // Centralized cleanup for all allocated resources.
    if (pAdministratorsGroup)
    {
        FreeSid(pAdministratorsGroup);
        pAdministratorsGroup = NULL;
    }

    // Throw the error if something failed in the function.
    if (ERROR_SUCCESS != dwError)
    {
        throw dwError;
    }

    return fIsRunAsAdmin;
}
// 

If IsAppRunningAsAdminMode returns TRUE, then there is nothing left to be done, and everything is OK to continue with any task.

If it returns FALSE, then we need to elevate.

How to Elevate

The way we elevate during runtime is obtaining the application name and path and executing it elevated to "Admin", while the currently running instance, of course, must terminate.

We also need to address the scenario in which the end user refuses to confirm this elevation, which is addressed, as you can see in the following code:

wchar_t szPath[MAX_PATH];
if (GetModuleFileName(NULL, szPath, ARRAYSIZE(szPath)))
{
    // Launch itself as admin
    SHELLEXECUTEINFO sei = { sizeof(sei) };
    sei.lpVerb = L"runas";
    sei.lpFile = szPath;
    sei.hwnd = NULL;
    sei.nShow = SW_NORMAL;
    if (!ShellExecuteEx(&sei))
    {
        DWORD dwError = GetLastError();
        if (dwError == ERROR_CANCELLED)
        {
            // The user refused to allow privileges elevation.
            std::cout << "User did not allow elevation" << std::endl;
        }
    }
    else
    {
        _exit(1);  // Quit itself
    }
}  

Running My POC

I have written a little POC to demonstrate this idea.

After pressing "Y", the application will try to elevate itself, only if it is not run in Admin privileges already.

History

• 27^th January, 2012: Initial version