Create​ProcessAs​User

The docs say that CreateProcessAsUser requires a Primary Token which I can receive by calling LogonUser.

Is there any way that a process can retrieve such a token for the account under which it is already running without needing to know the login credentials for that specific account?

Then the process could pass a handle to this token to an admin process which can then use it in a call to CreateProcessAsUser?

This is Vista, and I need some way for a process which is running as admin to launch a process under a specific user account.

This is driving me nuts, it is easy for a regular user to launch an admin program via User Account Control, but there is no way for that admin process to turn around and launch a process as that regular user!

You can't successfully launch a process as a Standard User from an elevated process, without introducing subtle security issues.

Consider the following scenario:

• User A (a standard User) launches app X
• X requests Administrative rights to run task Y
• User B provides over the shoulder elevation credentials
• Task Y runs with User B's full token
• Y now tries to "un-elevate" to run task Z
• Z runs as user B
  

User A has now successfully gained access to anything restricted to User B.

The only way to did with this type of scenario correctly is the 'bootstrap' model. The initial process runs as a standard user by flagging it with a requiredExecutionLevel of asInvoker. Where necessary it elevates to perform administrator actions. If any additional actions need to be performed as the standard user, IPC should be used to notify the original proven which can then initiate the task in the correct context. This is most easily achieved by using COM elevation.

AndyC wrote:



You can't successfully launch a process as a Standard User from an elevated process, without introducing subtle security issues.

Consider the following scenario:

• User A (a standard User) launches app X
• X requests Administrative rights to run task Y
• User B provides over the shoulder elevation credentials
• Task Y runs with User B's full token
• Y now tries to "un-elevate" to run task Z
• Z runs as user B
  

User A has now successfully gained access to anything restricted to User B.

The only way to did with this type of scenario correctly is the 'bootstrap' model. The initial process runs as a standard user by flagging it with a requiredExecutionLevel of asInvoker. Where necessary it elevates to perform administrator actions. If any additional actions need to be performed as the standard user, IPC should be used to notify the original proven which can then initiate the task in the correct context. This is most easily achieved by using COM elevation.

First of all, thank you very much for your reply.

You say that what I want to do introduces security issues, but the "CreateProcessAsUser" function does exist for some purpose, right?
Why does it exist if I shouldn't use it?

In my specific case, the initial process which runs as the regular user MUST exit after it launches the admin app, because the admin app is an updater program that must be allowed to replace application binaries.  Then, the updater should re-launch the application after it has been updated.  So I need it to launch it as the user who was using before the update.

troposphere wrote:


You say that what I want to do introduces security issues, but the "CreateProcessAsUser" function does exist for some purpose, right?
Why does it exist if I shouldn't use it?

There are plenty of legitimate uses for it where it does the job admirably. This isn't one of them.

troposphere wrote:



In my specific case, the initial process which runs as the regular user MUST exit after it launches the admin app, because the admin app is an updater program that must be allowed to replace application binaries.  Then, the updater should re-launch the application after it has been updated.  So I need it to launch it as the user who was using before the update.

The trick is to not make the updater require Admin rights (at least not initially).

The sequence of events should go:

1. Initial process detects need to update.
2. Updater is launched as standard user
3. Initial process quits
4. Updater uses COM elevation to create object with Administrative rights
5. COM object updates files
6. Control returns back to updater process
7. Updater launches new version of initial process

If you don't want to use COM elevation, you could introduce a third process, but that is rather untidy and may lead to issues it you want Logo certification.

AndyC wrote:



The trick is to not make the updater require Admin rights (at least not initially).

The sequence of events should go:

1. Initial process detects need to update.
2. Updater is launched as standard user
3. Initial process quits
4. Updater uses COM elevation to create object with Administrative rights
5. COM object updates files
6. Control returns back to updater process
7. Updater launches new version of initial process

If you don't want to use COM elevation, you could introduce a third process, but that is rather untidy and may lead to issues it you want Logo certification.

Oh, alright, now I see what you mean. 

But the only problem is that the updater program is already 99% written.  Does it have to be rewritten to use this COM Elevation method?

I humbly admit that I don't know much about COM beyond some of the most basic concepts of aquiring interface pointers and checking return values.

troposphere wrote:



AndyC wrote:  The trick is to not make the updater require Admin rights (at least not initially). The sequence of events should go: Initial process detects need to update. Updater is launched as standard user Initial process quits Updater uses COM elevation to create object with Administrative rights COM object updates files Control returns back to updater process Updater launches new version of initial process If you don't want to use COM elevation, you could introduce a third process, but that is rather untidy and may lead to issues it you want Logo certification.

Oh, alright, now I see what you mean. 

But the only problem is that the updater program is already 99% written.  Does it have to be rewritten to use this COM Elevation method?

I humbly admit that I don't know much about COM beyond some of the most basic concepts of aquiring interface pointers and checking return values.

If you're lazy, just start another executable up which contains all of your administrative-only code (or the same executable with command-line options)

evildictaitor wrote:



troposphere wrote:  AndyC wrote:  The trick is to not make the updater require Admin rights (at least not initially). The sequence of events should go: Initial process detects need to update. Updater is launched as standard user Initial process quits Updater uses COM elevation to create object with Administrative rights COM object updates files Control returns back to updater process Updater launches new version of initial process If you don't want to use COM elevation, you could introduce a third process, but that is rather untidy and may lead to issues it you want Logo certification. Oh, alright, now I see what you mean.  But the only problem is that the updater program is already 99% written.  Does it have to be rewritten to use this COM Elevation method? I humbly admit that I don't know much about COM beyond some of the most basic concepts of aquiring interface pointers and checking return values.

If you're lazy, just start another executable up which contains all of your administrative-only code (or the same executable with command-line options)

I think this is what I'll do.  But it's not due to laziness, it's due to the fact that the deadline is very near, and I know next to nothing about COM, and I don't have time to rewrite the whole updater.