Can Project Reunion enable FullTrustProccess-UWP apps that access win32 process to start as "Run As Administrator" on Desktop Shell?

[77376]

Proposal: Can Project Reunion enable FullTrustProccess-UWP apps that access win32 process to start as "Run As Administrator" on Desktop Shell?

Summary : Since Project Reunion is all about merging win32 and UWP features, so I think this proposal fits here.

packaged or unpackaged win32 apps can use this in the context menu.
but Apps like "Files UWP" that are FullTrustProccess-UWP apps/access win32 process can't do so.

On the Desktop Shell, It shoud have a Context Menu having "Run As Administrator" as an option to start with.

[ptorr-msft]

Thanks for the issue (now a discussion). This is something that is interesting but is tied up in a larger issue of how "run Full Trust" works; I'm actually writing up a spec on this right now so it's good timing (reminder: just because someone at Microsoft is typing into a Word document, doesn't mean it's a feature that will ship any time soon :) ).

Without going into too much detail, "UWP" (by definition) is also known as "Low IL" (IL = Integrity Level) and running apps as Administrator (or "elevated") is "High IL." Normal Win32 apps (including Desktop Bridge and runFullTrust processes) run at "Medium IL." So as it stands, "UWP" apps cannot launch elevated by-design.

The original design of runFullTrust was that Desktop devices would let you spawn Medium IL processes via FullTrustProcessLauncher, and other non-Desktop devices would simply ignore it. At runtime, apps would check if the FullTrustProcessLauncher type was present, and if so they would call the API otherwise they would avoid it. So apps could be Universal and have basic functionality everywhere but light up more features on Desktop. (Or, more likely, the package would just have windows.fullTrustProcess entry points and would explicitly be Desktop-only).

For various reasons, runFullTrust doesn't quite work like that anymore and it is basically synonymous with Desktop right now. Additionally, runFullTrust doesn't support user consent (e.g. like the popups you see for camera or geolocation) which means there is no way for a user to turn it off without uninstalling the application. And the OS can't just add that toggle after-the-fact since ~most apps would likely crash if they were suddenly run without the capability in effect. Uninstall is your only recourse.

So... we are thinking about making a new "optional full trust" feature, meaning the app explicitly tells OS it would like to run Medium IL processes, but the user gets to decide and the app can successfully run without it. Until we have unified app lifecycle, this would still be limited to a Low IL app launching Medium IL processes via FullTrustProcessLauncher, but eventually it would support launching the main app itself either at Low or Medium IL, depending on the user's choice. And at that point, we could also support launching at High IL via the shell context menu etc.

In that design, this is primarily an ask for the unified app lifecycle (so you can run the exact same binary at either Low or Medium IL) and from there it's some additional manifest goo and UI to also enable elevation. Does that sound like it's reasonable? Any feedback on the high-level design?

Of course, this is only useful if you want to run at Low IL in the first place, e.g. so you can run on HoloLens or because you want to give customers the choice to minimize security & privacy exposure. If you don't care about Low IL then you should just be a Medium IL app (using Win UI or whatever other "UWP" features you need) and then you would get elevation for free, just like it works today.

[77376]

@ptorr-msft

So... we are thinking about making a new "optional full trust" feature, meaning the app explicitly tells OS it would like to run Medium IL processes, but the user gets to decide and the app can successfully run without it. Until we have unified app lifecycle, this would still be limited to a Low IL app launching Medium IL processes via FullTrustProcessLauncher, but eventually it would support launching the main app itself either at Low or Medium IL, depending on the user's choice. And at that point, we could also support launching at High IL via the shell context menu etc.

In that design, this is primarily an ask for the unified app lifecycle (so you can run the exact same binary at either Low or Medium IL) and from there it's some additional manifest goo and UI to also enable elevation. Does that sound like it's reasonable? Any feedback on the high-level design?

Thanks a bunch for explaining things in detail.
(1.) so, will new "optional full trust" feature be implemented in future (then eventually allow running at High IL on Desktop via the Shell context menu) , once #111 /"Unified App Lifecycle" gets implemented ?"

If you don't care about Low IL then you should just be a Medium IL app (using Win UI or whatever other "UWP" features you need) and then you would get elevation for free, just like it works today.

(2.) Isn't a Medium IL UWP app restricted to run on Desktop only?

[ptorr-msft]

Isn't a Medium IL UWP app restricted to run on Desktop only?

Yes, if you want to run on non-Desktop platforms you need to be Low IL.

And yes, once we have unified lifecycle then adding elevation should be incremental.

[soumyamahunt]

@ptorr-msft what about allowElevation capability for uwp apps?? Capability documentation describes apps with these capability will be rejected from Store submission. Is it still the case since now Win32 apps are allowed in store??

[ptorr-msft]

allowElevation is for packaged Win32 apps. I don't know current Store policy, sorry.