sylveon commented 3 years ago

Proposal: AppContainer for Win32 apps

Summary

This proposal attempts to bring the advantages of app containers (limited permissions and file system access) to Win32, by documenting how a packaged Win32 app can be hosted in one, and allowing Win32-only APIs which are not currently allowed to be called from an AppContainer.

Currently, this can be achieved by using EntryPoint="Windows.PartialTrustApplication" in the appx manifest. By setting this, your Win32 app is launched in the AppContainer:

But, this entry point is largely undocumented (its only reference on the entire internet is an electron PR), and some things are broken.

For example, tray icons (with ShellNotifyIcon) are simply not working, and return an access denied error.

OpenProcess, even with only the PROCESS_QUERY_LIMITED_INFORMATION permission, also returns an access denied. This permission is mostly harmless and only allows a very limited subset of APIs, none of which can do anything harmful to the process. There is little to zero security implication in allowing this.

As the screenshot above shows, I've tried doing this with my own app, and these are the two big limitations I've encountered (as well as the general lack of documentation around this topic).

Rationale

This makes Win32 apps safer for everyone. Long gone are programming mistakes or bugs that would accidentally wipe your whole drive.
Allows to host Win32 apps in Windows 10X natively, without the need for virtualization. Since Win32 apps in AppContainers are under the same restriction than UWP apps, there is no need to use an expensive virtualization stack to run them, but instead a thin compatibility layer (if any). By doing this, it makes Win32 apps faster and more energy efficient under 10X.
Allows developers to ship Win32 apps to the Microsoft Store without requesting access to the runFullTrust restricted capability
- This would allow to make sandboxing more fine-grained rather than all or nothing, for example a specific restricted capability to enable more process access permissions under the sandbox.
- It can also bring the possibility to lockdown runFullTrust to apps that actually do need to run completely outside the container for legitimate reasons, rather than every Win32 app.

Scope

Capability	Priority
This proposal will allow developers to host Win32 apps in the AppContainer with ease	Must
This proposal will allow developers to use tray icons from within an AppContainer	Must
This proposal will allow developers to call Win32-only APIs which are not security risks from within the AppContainer	Must
This proposal will allow developers to use a full trust helper along their partial trust Win32 app	Should
This proposal will introduce new restricted capabilities that would allow some normally restricted API calls to work	Could
This proposal will bring UWP privacy controls to packaged Win32 apps	Could
This proposal will allow developers to completely escape the AppContainer	Won't

Important Notes

My app uses, along the things mentioned prior:

SetWindowsHookEx to inject Windows Explorer (this is required for core functionality to work correctly)
PROCESS_VM_OPERATION, to be able to inject a payload that the hooked DLL can read for contextual information (related: https://github.com/microsoft/WinDev/issues/28)
SetWinEventHook to know changes that happen to the window layout (opened, moved, maximized, minimized, closed, etc).
SendMessage, to be able to trigger a refresh of the taskbar's theme in Windows Explorer.

While SetWinEventHook seems to already work today in the AppContainer (hooray), other APIs mentioned would need to be moved to a full trust helper. If this proposal where to come to fruition, I would be one of the first to jump unboard and move that functionality to a helper process.

This is part of the reason I suggested to introduce new restricted capabilities which would unblock some APIs, as simply unlocking specific APIs under request is far safer and simpler than making a full trust helper process.

Open Questions

Would it be beneficial for anybody to introduce a partial trust equivalent to FullTrustProcessLauncher?

torarnv commented 1 year ago

You're right! It actually seems to work. At first I got this when building:

But after bumping that, the resulting XML now has:

Hurray! 🥳