The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
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)
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?
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 thePROCESS_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
runFullTrust
restricted capabilityrunFullTrust
to apps that actually do need to run completely outside the container for legitimate reasons, rather than every Win32 app.Scope
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
?