FAQ: How do I start a program as the desktop user from an elevated app?

re: FAQ: How do I start a program as the desktop user from an elevated app?

Jeremy Bettis — Sat, 06 Jun 2009 22:28:06 GMT

What about ShellExecute? Won't that run as the shell's user?

[Aaron Margosis] Not normally, no. The immediate process that gets launched will run with your elevated token. If it is a single instance program (like Explorer) that is already running, then you'll usually get something running in that initial process, but other than that, no.

re: FAQ: How do I start a program as the desktop user from an elevated app?

AndyC — Sun, 07 Jun 2009 02:29:38 GMT

And that's *still* buggy. Off the top of my head:

1) Doesn't work if the app is launched directly through Terminal Services, because then the shell isn't running.

2) Doesn't work in complex chains, e.g. User A launches a command prompt via runas as User B, then that launches your app and does an OTS elevation to User C. Your code then runs the unelevated code as User A, not User B as it should.

The only 100% safe way of doing this is to use a bootstrap model. You start by launching an unelevated "bootstrap" app, that starts your elevated process which does the admin work and once it has completed, the bootstrapper launches whatever process you want, which is guaranteed to be in the correct user context.

[Aaron Margosis] That depends on your definition of "buggy". I was careful to say "run the app as the non-elevated desktop user" -- if there is no non-elevated desktop, then there's no correct answer. The bootstrap model won't work in that case either.

Re #1 and terminal services: I can't repro this -- when I try to configure the "start a program" option in mstsc, it has no effect (going from a Vista SP1 to another one). I tried a bunch of different ways, but no luck. The shell just comes up each time. Can you specify an app that requires elevation? What happens when you do?

Re #2 and "not User B as it should." (emphasis mine.) First of all, this seems an odd edge case -- under what non-contrived scenarios are you going to have a chain of three independent security contexts? And why do you assert that the non-elevated app should run as User B and not as User A? How do you know that the User B context is not elevated too? Is that an elevated command prompt?

The bootstrap model is another model that can be appropriate in some scenarios. However, it is not "100% safe". That model builds in an assumption that the bootstrap app was started in a "safe" non-elevated context. What if the user started the bootstrap app with elevation or from an elevated CMD? Then everything runs elevated.

Second, the bootstrap model is more complex. If the bootstrap app needs to do more than simply wait for the elevated process to exit, then you need to build interprocess communication between the two processes so that the elevated app can tell the bootstrap app "now do XYZ." It's not impossible, of course, but it's much more complex than my sample. (And of course, complexity increases risk of bugs, and those can easily be security issues in a scenario like this.)

Third, sometimes the bootstrap model is simply not appropriate. Say you've built an app that legitimately requires admin rights (my favorite example is Process Monitor). The app has a feature or two that is rarely used but needs to launch a browser -- like Procmon's "search online" feature. In order to use the bootstrap model, Procmon would always need to be started non-elevated, and would need to keep that non-elevated bootstrap app around as long as Procmon were running, just in case the "search online" feature got invoked. That makes no sense to me at all.

[Added moments later] There actually is a bug in here -- the code that enables SeIncreaseQuotaPrivilege should not do so on the process token -- it should do so in the context of the thread and then revert: ImpersonateSelf, OpenThreadToken, manipulate token, perform operations, RevertToSelf. Fixing that is left as an exercise for the reader :)

[One more late comment] In your complex chain scenario, if the "non-elevated" app you want to start is IE7, it will refuse to run as User B.

re: FAQ: How do I start a program as the desktop user from an elevated app?

Bob — Mon, 08 Jun 2009 14:53:30 GMT

Why MS doesn't provide a nw API that returns the token that was used when launching the program that causes the evelation prompt?

re: FAQ: How do I start a program as the desktop user from an elevated app?

AndyC — Tue, 09 Jun 2009 06:34:10 GMT

#1 requires a real Terminal Server, I believe. I don't think it's supported on client versions. Though it's possible similar behaviours exist when using the Desktop Sharing APIs, so tools like Meeting Space or Remote Assistance may break too.

#2 I've mostly seen that sort of complex setup when dealing with domains where security was a big issue that were XP oriented, so that multiple user accounts were used to avoid running with a privileged token at all times. Obviously, to some extent, UAC helps to make that sort of thing unnecessary.

100% safe was perhaps badly worded, it's the only way to ensure what is the usual intent in such scenarios, i.e. to launch in the context of whomever started the application. Had it been an elevated context in the first place, it wouldn't have gone through UAC to change identity again, so that's not really an issue. Ultimately if the end-user has gone out of there way to launch your app such that everything it does is elevated, you ought to let them do so, they might know something you don't.

As to apps like Process Explorer, they're mostly an edge case too, this sort of question mostly comes up around application installers and for them the bootstrap model is always the best way to go.

[Aaron Margosis] It sounds to me that you're extrapolating your own experiences to a much broader universe that you can authoritatively speak on behalf of. Your "usual intent" may be minority. I'd disagree that users always understand all the implications of their actions, or that any model is "always" the best one for all scenarios. I'll reiterate the browser example, which I doubt is uncommon -- many app installers display a readme using the default web browser, and other elevated apps may also display HTML that way. Since the bootstrapper cannot guarantee that it will always be launched as the desktop user -- not only as a non-admin, but as the desktop user -- that scenario breaks pretty badly.

That said, I don't really think the bootstrap model is that much more complicated, especially if you use COM elevation rather than spawning an entirely different executable to create an elevated context. And "it's more effort to do right" is a poor excuse when it comes to security, don't you think?

[Aaron Margosis] Doing COM elevation correctly without exposing trivially exploitable EoP is not simple. Those communication paths have to be carefully threat-modeled and implemented. And "It's more effort to do right" does not reflect what I said at all. If it's the best approach, the extra effort is often worth it. Shoehorning that model where it doesn't belong only adds effort and increases risk without providing value.

re: FAQ: How do I start a program as the desktop user from an elevated app?

Roy Folkker — Wed, 15 Jul 2009 22:05:19 GMT

Having worked on installers (and bootstraps) extensively, I have to say that using the bootstrap as your non-elevated point for a split level execution is not only a bad idea, but very impractical. In the case of my current work, my bootstrapper actually performs the execution of the MSI package through API calls. As well, it can perform patches, and launch executables through a series of prerequisites. Assuming I choose to have it run as invoked, or as user, that means that every prerequisite will require UAC confirmation (retrieving the token from the process will not work since MSP and MSI function calls do not allow me to elevate them), and once an MSI or MSP package hits a required elevation action, my executable will be elevated, since it is not a parent process, it is the current process, rendering all other considerations moot.

With all of that aside, there is the ever popular issue of Microsoft key words for UAC. If you name an executable setup, update, or some variations there-in, congratulations, you are elevated. Again, rendering the bootstrap as a non-elevated launch point as moot.

[Aaron Margosis] Installer detection is only for "legacy" apps. If the app has a Vista-aware manifest (i.e., specifies requestedElevationLevel), it overrides installer detection, so you can have an app called setup.exe that doesn't prompt for elevation. By default, Visual Studio 2008 adds a Vista-aware manifest to apps you build.

So, either way, from an installer stand-point, *most* if not all situations will have a default shell. If you are installing software via TS to a terminal server, and succeeding you deserve an award (or to be taken out back for doing something that scary). So, the concept of creating your non-admin tool processes as user through an Admin process seem far more beneficial (especially considering in most situations you *want* to be as admin in an install process, with very rare non-admin addendums (e.g. launching an external read-me, launching a Support page, and such).

Anyways, thank you for the information here. Again, Mr. Margosis you have provided information that has been unbelievably useful and just incomplete enough to force me to make sure I know what I am doing:P.

[Aaron Margosis] Incomplete? Even with the code sample?

re: FAQ: How do I start a program as the desktop user from an elevated app?

Roy Folkker — Thu, 16 Jul 2009 01:40:53 GMT

Still on 2005, so I haven't seen the difference in manifests yet.

As for your other statement, sorry, hadn't started working with it, just took your previous statement at face value:).

[Added moments later] There actually is a bug in here -- the code that enables SeIncreaseQuotaPrivilege should not do so on the process token -- it should do so in the context of the thread and then revert: ImpersonateSelf, OpenThreadToken, manipulate token, perform operations, RevertToSelf. Fixing that is left as an exercise for the reader :)

re: FAQ: How do I start a program as the desktop user from an elevated app?

ilmcuts — Fri, 17 Jul 2009 13:05:59 GMT

Alternatively you can use the IShellDispatch2 interface:

http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/

It still needs the Explorer shell to be running, but if you're willing to live with that then this approach seems much easier. And you don't even need to special case Vista/Win7 as the code should work on XP as well.

re: FAQ: How do I start a program as the desktop user from an elevated app?

Boon Hong — Thu, 27 Aug 2009 19:00:57 GMT

In my case, I am creating a flash application as the interface to execute some programs and installers from the disc.

Since I need to execute the installers in elevated mode, I have to amend the default manifest in the flash application to launch in elevated mode too. But by doing this, I will cause all programs launched from flash to be in elevated mode. This is a potential security leakage.

It will be good if Microsoft can provide a command line utility to downgrade the elevated mode that can be executed from batch files.

It will even be better if Microsoft is willing to fix this security loophole by having all child process to be launched in non-elevated mode by default just like all applications are launched in non-elevated mode by default.

re: FAQ: How do I start a program as the desktop user from an elevated app?

Bill Zitomer — Wed, 11 Nov 2009 13:10:19 GMT

This is great material, thanks for posting. The problem I have, this method works for me for running an exe with a manifest that does not require elevation. But it appears that if the manifest is set to require elevation, then CreateProcessWithTokenW returns 740 (elevation required) even though I'm trying to run it non-elevated.

I've tried a number of variations. I was previously using CreateProcessAsUser to lower the integrity, which works fine, except the process still runs as the admin.

I'm about to try the IShellDesktop2 interface to see if it might work any better.

[Aaron Margosis] The only way I know of to override the "requireAdministrator" manifest is to apply the RunAsInvoker application compatibility shim.

re: FAQ: How do I start a program as the desktop user from an elevated app?

Bill Zitomer — Thu, 12 Nov 2009 03:19:16 GMT

Yeah that's not going to work in this case because I need to distribute. What I have is a custom install process which needs to read a cookie left by our web site. The cookie resides in the low cache, which the installer cannot access. What I did is re-run the installer as a low integrity process and use InternetGetCookie, which works fine if the user is an admin, but for standard user it fails because it's still running as admin, whereas the cookie left by IE was running as the user. I ended up making a new exe with runAsInvoker in the manifest and I think this will work. I will need to embed it, extract at run time, etc. All of this to do what used to be one line of code!

re: FAQ: How do I start a program as the desktop user from an elevated app?

Bill Zitomer — Thu, 12 Nov 2009 04:40:48 GMT

ha! I can do this much more simply with impersonation.

re: FAQ: How do I start a program as the desktop user from an elevated app?

Suresh — Fri, 13 Nov 2009 15:21:50 GMT

Hi,

I have a setup application which will be launched from a device driver co-installer dll. My requirement is the setup application has to launch an URL in protected mode. I followed the article given in

http://msdn.microsoft.com/en-us/library/bb250462%28VS.85%29.aspx. But it doesn't help much.

I also downloaded the sample application given in this article and tried. But IE is still launching with protected mode off.

As driver installation happens using admin privileges the setup application is launching with admin privileges and IE also launching with admin privileges hence protected mode is off. Is there a way how we can launch IE with Protected mode ON in this situation?

Help!.

Thanks & Regards

Suresh

[Aaron Margosis] Why does it matter whether Protected Mode is on or not? Note that PM will be off for the Trusted Sites and Local Computer zones, as well as for the Intranet zone (for IE8).