WindowsAppSDK
WindowsAppSDK copied to clipboard
AppContainer for Win32 apps
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
?