At its annual Build conference last month, Microsoft announced the ability to run Win32 apps in isolation on Windows 11. The company didn’t go into a lot of detail in its initial blog post, but it highlighted the option to run Win32 apps in a sandbox environment so that the rest of the operating system is secure from potentially malicious software. Now, it has revealed more information about this particular capability, including how it works and fits into the rest of the security infrastructure of Windows.
Microsoft’s Vice President of OS Security and Enterprise David Weston has penned a lengthy blog post, explaining the nature of Win32 app isolation. The feature is yet another sandbox security option just like Windows Sandbox and Microsoft Defender Application Guard, but it is based on AppContainers, not virtualization-based software like the other two security measures. For those unaware, AppContainers serve as a way to control the execution of a process by encapsulating it and ensuring that it runs at very low privilege and integrity levels.
Microsoft has strongly recommended using Smart App Control (SAC) and Win32 app isolation in tandem while securing your Windows environment from untrusted apps that utilize 0-day vulnerabilities. The former security mechanism stops attacks by installing only trusted apps while the latter can be used to run apps in an isolated and secure environment to limit potential damage and protect user privacy. This is because a Win32 app running in isolation does not have the same privilege level as the user of the system.
The Redmond tech firm has identified several key goals of Win32 app isolation. For starters, it limits impact from a compromised app since attackers have low privilege access to a portion of the operating system, and they would need to chain a complex, multi-step attack in order to break through their sandbox. Even if they are successful, this gives more insight into their process as well, making it much faster to implement and deliver mitigation patches.
The way that this works is that an app is first launched at low integrity levels through AppContainer, which means that they have access to select Windows APIs and cannot execute malicious code which require higher privilege levels. In the next and final step, the principles of least privilege are enforced by giving an app authorized access to Windows securable objects, which is equivalent to implementing a Discretionary Access Control List (DACL) on Windows.
Another advantage of Win32 app isolation is reduced developer effort as app creators can leverage the Application Capability Profiler (ACP) available on GitHub to understand what permissions they exactly need. They can enable ACP and run their app in a “learn-mode” in Win32 app isolation to get logs about the additional capabilities they need to run their software. ACP is powered by the Windows Performance Analyzer (WPA) data layer backend and Event Trace Logs (ETLs). The information from the logs generated by this process can simply be added to an application’s package manifest file.
Finally, Win32 app isolation aims to offer a seamless user experience. Win32 app isolation facilitates this by requiring apps to use the “isolatedWin32-promptForAccess” capability to prompt the user in case they require access to their data such as .NET libraries and protected registry keys. The prompt should be meaningful to the user from whom consent is being obtained. Once access to a resource is granted, this is what happens next:
When the user grants consent to a specific file for the isolated application, the isolated application interfaces with Windows Brokering File System (BFS) and grants access to the files via a mini filter driver. BFS simply opens the file and serves as the interface between the isolated application and BFS.
File and registry virtualization helps ensure that apps continue to work while not updating the base file or registry. This also minimizes any user experience friction while maintaining application compatibility. Protected namespaces are created to allow access only to the app and do not require user consent. For example, access to a folder that has a property only known to the Win32 app and required for app compatibility can be granted.
Microsoft has emphasized that in order to have feature parity between isolated and non-isolated Win32 apps, the former can interact with the file system and other Windows APIs by leveraging Windows BFS. Moreover, entries in the application’s manifest also ensure that the app can safely interact with Windows elements like shell notifications and icons in the system tray. You can learn more about the initiative on GitHub here.