Launching an administrative interactive process when a standard user is logged on

Question

I have a system service which creates a helper interactive process as administrator so that it can access some desktop-related resources, including the BlockInput() function and NVIDIA's NVAPI functions, which cannot be run from a service. When the logged on user was a member of Administrators, the following worked:

1. Set privilege levels, including SE_TCB_NAME
2. Get active session ID with WTSGetActiveConsoleSessionId()
3. Get logged on user from session ID with WTSQueryUserToken()
4. GetTokenInformation() with TokenLinkedToken
5. DuplicateTokenEx() with SecurityImpersonation
6. Launch process with CreateProcessAsUser()

However, when I have the current logged on session be a standard user instead of one in Administrators, step 4. fails, presumably because the standard user doesn't have an administrative level token linked with it. What's the solution here? I assume I need to get the token of one of the administrator users, but how do I do that? And if that user is not the logged on one, can it still access functionality interactive with the current desktop?

Answer 1

You can duplicate your own token, then change the session on the duplicated token using the SetTokenInformation function to put it into the interactive session.

As you note, running as SYSTEM in an interactive session is discouraged because it gives the interactive user openings to attack your process, potentially gaining elevated privileges. (Search for "shatter attack" for more information.) However, this concern applies equally well to a process running as an administrative user in a non-administrative user's session.

Ideally, you should use a non-administrative process in the interactive session, to perform functions which require an interactive session, while using the service to perform functions which require administrative privilege. There shouldn't be any functions that require both, but if NVAPI breaks this rule, there's not much you can do about it.

Consider launching the process into a specially created (and appropriately secured) workstation in the interactive user's session in order to minimize this risk.