Projectreunion: Proposal: Bring ProcessLauncher to desktop

[Jaiganeshkumaran]

Proposal: Bring ProcessLauncher to desktop

Today it's not possible to launch a executable file or other files like .bat in a native UWP. While this makes it secure, it also locks it down. On IoT devices there's the ProcessLauncher class but that doesn't work on desktop.

Summary

A Win32 app can launch any file type but a UWP app can only launch content files except on IoT using the ProcessLauncher API. While most apps don't need to launch a executable file from a random location, apps like file managers might need to. Today the solution for that is to use a full trust component but that's not really convenient. For security, this should be a restricted capability on desktop and every time an app tries to launch a executable including low privileged executables, Windows should ask the user when he/she wants to run it and also the dialog box should show the publisher, version and other relevant information.

Rationale

• File managers and other apps don't need to depend on full trust just for launching a executable.

Scope

| Capability | Priority |
| :---------- | :------- |
| This proposal will allow developers of UWP apps to launch executables from any location if the app has the permission to the location | Must |
| This proposal will allow developers of UWP apps to launch executables from any location silently | Won't |

[stevewri]

@axelandrejs - could this be accomplishe by having a capability to launch apps, and add helper brokering to deal with user consent?

[ptorr-msft]

See somewhat related discussion here.

Basically, if a package has runFullTrust then yes it "should" be allowed to launch external processes at Medium IL. This includes not just explicitly creating processes via ProcessLauncher or FullTrustProcessLauncher (or ideally, plain old CreateProcess / ShellExecute) but also implicitly creating them via COM out-of-proc servers (like Office).

The current design of FTPL was focused on least-privilege, which in isolation is A Good Thing. Basically, if your app was well-structured with most of the code in the Low IL process (UI, business logic, etc.) and then a set of single-purpose Medium IL processes (with limited - if any - way to communicate with them), then if the UI process was compromised (e.g. by an exploit in the WebView) then the worst it could do was launch those single-purpose exes and so the damage was limited to whatever those could do. So say you had only one full-trust exe and it was designed to send e-mail to a fixed e-mail address with a fixed message via MAPI (e.g. to ask for product support). If the app is compromised, all it can do is send those e-mails. It can't do arbitrary things like steal data, encrypt files, etc.

Even if there is a richer form of communication between the UI and the full-trust exe -- for example, it brokers access to a local SQL Server instance and thus needs to send queries / results back and forth via AppServices or some other mechanism -- the damage is limited to whatever you can do via those SQL queries (which could be quite damaging).

The problem is that apps typically aren't that well-defined. Those full-trust exes do various things, and it's hard to build a proper security boundary between the two apps and properly sanitize inputs etc. especially if you start to use native IPC mechanisms like pipes or shared memory. You end up cobbling together a weird multi-process model with complex IPC contracts "just" to launch an external exe. Clearly this has big problems if your UI app is compromised -- now the attacker basically can run anything they want at Medium IL -- but... that's what would have happened _if you built a full-trust app in the first place_. So net-net, probably not that much of a benefit for apps in general.

So... my opinion is Yes, we should support this. We can still support the well-structured apps that have single-purpose helpers, and we can allow apps to opt-in to a more open model. That said... not sure when it would ship :).

[Jaiganeshkumaran]

One thing that I forget to point out was if the app is trying to launch an executable that isn't in the path, the app must have access to that location to launch. Launching without access to that location should not work unless the location is in path.

[ptorr-msft]

Normal ACLs would prevent you from launching any file that the app doesn't have access to (although by default it has access to the Windows and Program Files directories). Note however that this is a pretty minor thing; if the app doesn't have access to an exe, but the user does, then all you need to do is launch cmd /c path-to-exe and away you go.