Win32 App Isolation
github.com
github.com
Surfacing this new sandbox feature looks very easy from the instructions, but before it's worth doing I'd want to talk to the product teams involved and get answers to some questions:
1. What's the purpose of this? Is it to let users install potentially malicious apps in the same way you can browse to untrusted web pages? Or is it like how Apple pitches their app sandbox on macOS, purely an opt-in security feature to reduce the blast radius of exploits? The big difference is whether permissions are surfaced in the UI.
2. If you want permissions to be visible somewhere in the UI, then presumably that would be in App Installer. Conveyor replaces App Installer with its own installer that drives MSIX via the API because App Installer is too buggy to rely on. What's the plan for fixing that?
3. Relatedly, Conveyor contains a large number of workarounds for bugs in the Windows app container and package management system, especially older versions. This has ended up being a significant part of the value the product provides, even! It seems faintly ridiculous, but the Windows package manager does actually provide a lot of useful features like silent background updates (Chrome style) and it's core to Microsoft's platform strategy. But unless Microsoft's plan is to tell everyone to buy my product (yes please) they will need to fix the bugs. Are you going to do that? Otherwise devs will bounce right off it just as they have with every other feature Microsoft adds to Windows that relies on package identity.
4. Not only fix the bugs but also, will you backport the fixes to Windows 10? I can't stress this enough. Shipping MSIX packages outside the MS store without using Conveyor is just flat out impossible if you're targeting Windows 10, because you'll quickly hit bugs that Microsoft know about but never backported the fixes for.
Microsoft people - if you want to talk, feel free to email. Address is in the profile. We can tell you what issues people hit in the wild when they ship apps this way, and maybe work together on making this a success.
Have you considered making this installer open-source, and then asking Microsoft to co-develop it and ship releases of it as a replacement for App Installer?
Wouldn't you prefer to have your build system just emitting .msix for Windows, with the expectation that all Windows systems will then run your good installer in response to opening any .msix?
See BlueHat IL talk on the matter,
There are no plans for Windows 10, beyond security fixes until 2025, it is done.
EDIT: There is a BUILD 2023 talk on the matter as well.
App Installer has a nice UX on the happy path, but then you quickly discover that it will just fail for a non-negligible percent of customers.
IMO it's not a coincidence that very few first-party teams distribute their software using MSIX outside the Store. MSIX outside the store is broken, and for whatever reason the team responsible for it doesn't seem to be addressing that.
Or you'll hit basic features which are missing. Like deploying services from your MSIX: win10 - no problem, server 2019 - are you mad? you want to deploy services on a server? of course they're not supported...
* .appx became .msix; the latter also works for Win32 apps
* UWP XAML/GUI evolved into WinUI, v3 of which doesn't target UWP
* Win32 app isolation—this news—grew out of AppContainers, which were used by UWP apps
That said, what's new here? You could package (.msix) Win32 apps with partial trust, IIRC. Does this remove the need for packaging?
See:
https://learn.microsoft.com/en-us/windows/win32/secauthz/app...
https://learn.microsoft.com/en-us/windows/win32/api/userenv/...
https://scorpiosoftware.net/2019/01/15/fun-with-appcontainer...
edit: To clarify, all MSIX packaged apps run in an app container called Helium, but it's a very soft one that isn't meant to sandbox anything. It just redirects file IO to a special directory so installs/uninstalls are clean. You can make app containers stricter. The Chrome sandbox does that, UWP sandboxed apps do that, and now they're adding support for more strictly sandboxing ordinary Win32 apps which would otherwise break when they tried to open a file in the user's home directory.
What is new here, is that this is the continuation to make all Win32 apps sandboxed.
Fair, I would say it's somewhat actively developed, for now... Which is maybe a step above UWP XAML.
Microsoft promised to open source WinUI 3 years ago, but it keeps getting pushed back in favour of other priorities. This isn't good for a healthy community, who can only report bugs, and never fix them.
(For context, Microsoft has been trying for 7 years various methods to get developers to please package their apps in some way. Almost nobody has ever bit - to the point the Microsoft Store only has been having some recent success by promising packaging isn't required.)
https://petri.com/microsofts-project-centennial-unsuccessful...
Learned Silverlight for Windows Phone development? Too bad, it's UWP now. And the XAML is incompatible.
Learned WinRT for Windows 8/8.1 app development? Too bad, it's UWP now. And the XAML is incompatible.
Packaged your App for APPX? Too bad, it's MSIX now.
You learned how to develop UWP apps? Too bad, the User Interface layer has been ripped out of UWP, it's now called WinUI 3, and it doesn't even run on UWP. Better port your UWP app back to Win32 now, I guess. Why did you even learn UWP again?
You went and learned WinUI 3 like we recommended? Well, unlike WinUI 2, it doesn't have a visual designer, and it doesn't have input validation, or a bunch of other WinUI 2 features. So, depending on what your app needs, you might have a mix of UWP and Win32, because WinUI 2 is UWP-exclusive and WinUI 3 is Win32-exclusive and neither has all the features of the other. Progress!
You built your Windows 8 app with WinJS? Well, sucks to be you, rewrite it in entirety, WinJS was scrapped.
You ported your app from iOS with Project Islandwood? Well, again, that sucks. It was brilliant, it made pulling apps over from iOS much easier, but it's dead. Rewrite!
You decided to hang it all, develop for good old WPF, but wanted to use the Ink Controls from UWP? Great, we developed a scheme for that called XAML Islands which made so you could have some of the best UWP controls in your old app. Then we released WinUI 3, completely broke it, and made it so complicated nobody can figure it out. So broken; even the Windows Team doesn't use it and is writing the modern Windows components for File Explorer with the old version.
But of course, that would require WinUI 2, for UWP, inside Win32 which is the main feature of the broken WinUI 3; which means that the Windows Team has a bastardized version of XAML Islands for their own use that nobody else has (literally), to modernize the taskbar and File Explorer and built-in apps like Paint, that nobody who wants to emulate them can borrow. Their apps don't look modern and their users complain? Suckers, go learn WinUI 3, even though our own teams couldn't figure it out.
You wanted your app on the Microsoft Store? Well, good news, package it together with this obtuse script that requires 30 command-line arguments, perfect file path formats, and a Windows 10 Pro License! Oh, you didn't do that? Do it 5 years later with MSIX and a GUI this time! Oh, you didn't do that? Forget the packaging, just submit a URL to your file download location. Anyone who bothered with the packaging wasted hours for no real purpose.
Did I mention Xamarin? A XAML dialect of its own, that supports all platforms. But it runs on Mono instead of the authentic .NET, so you'd better... work around the quirks. Also it's called MAUI now, and runs on .NET now. But that might break a few things so hang around for over a year's worth of delays. We'll get it running for sure!
Oh, and don't forget about ARM! The first attempt to get everyone to support ARM was in 2012 with a Windows version called... No, no, no. Go past this. Pass this part. In fact, never play this again. (If you want to imagine pain, imagine running Windows and Microsoft Office on a ARM CPU that came three generations before the Tegra X1 in the Nintendo Switch. Surface RT ended with a $900M write-off.)
And so on...
Or, you could just ignore everything, create a Windows Forms (22 years strong) or WPF app (17 years strong), and continue business like usual. Add in DevExpress or Telerik controls and you are developing at the speed of light. And if you need a fancier UI, use Avalonia, Electron, React, or Flutter.
Edit: Thank you for giving such a nice summary of the current landscape of UI dev in Windows native development.
I wonder why nobody's created a "XAML projector" to allow you to create Windows UI applications the same way — by writing some platform-neutral app in Java or whatever, that needs no native libs loaded into it, but rather just knows how to generate XAML and, when told it's running on Windows, expects to be connected to over a socket by an also-XAML-speaking client.
Or I could say the same about Qt's QML.
(In fact, at this point I have to wonder: if modern UI frameworks almost always use an intermediary "view definition language" to communicate with the application anyway, then why are they even designed to load as native libraries resident inside the process? Why not just reinvent the X protocol on a higher level — have the UI toolkit be a local (socket-activated) daemon, and then all the things that use it are just clients that speak its protocol? I know, you can't directly draw to the screen from your backend this way. X11 DRI worked, though, and IMHO was a very good idea — SHM buffers are way easier to get working in most language runtimes than an FFI binding of some C++ UI toolkit is. Or maybe we can do one better, these days: just expose WebGL commands addressable to WebGL canvas objects over the toolkit's protocol.)
I, for one, never stopped developing in WPF.
Modern JavaFX theme: https://github.com/mkpaz/atlantafx
Modern Swing theme: https://github.com/JFormDesigner/FlatLaf
And these days Compose Multiplatform: https://www.jetbrains.com/lp/compose-multiplatform/
I tend to use Kotlin rather than Java but of course Java is perfectly fine too. You can also use Clojure.
If you use any of those frameworks you can distribute to Win/Mac/Linux in one command with Conveyor. It's free for open source apps and can do self-signing for Windows if you don't want to pay for the certificates or the Store (but the Store is super cheap these days, $19 one off payment for an individual). Also supports Electron and Flutter if you want to use those.
From those frameworks you can then access whatever parts of the Windows API you want. Flutter even has WinRT bindings these days! So it's not quite so bad.
Worst part of WPF for me was the tooling that crashed whenever you so much as looked at it wrong.
But hey, from all the warts, and screw-ups, the other gardens aren't much better.
Avalonia, React (Native) and Flutter all seem to be doing pretty well as alternatives as well. All with cross platform support and less friction than the Microsoft solution(s) for this. That MS didn't support MAUI with at least Linux+GTK/Gnome from the start, who knows, it was a massive miss for a lot of devs imo.
As it turns out, Windows is nothing without Win32 which developers and users want. Consequently, Win32 has subdued every single attempt from Microsoft to replace it. Every. Single. Attempt.
The recent moves back to Win32 are essentially Microsoft finally throwing in the towel, though the jury is still out if they understand why Win32 keeps on slaying them at every turn.
And while I'm not aware of any way to sandbox Windows Installer itself, I'm curious if AppContainer isolation can be applied to applications and services installed via MSI, which would still be quite useful even if the installation process itself is unrestricted.
Alternatively, now that MSIX supports service installation[2], I wonder whether an MSIX including a Windows service and a collection of client applications can be configured so everything runs within one AppContainer, isolated from the rest of the system, and whether permission to access specific external directories chosen by users in a configuration GUI can be transparently (to the user) delegated to the related service.
Alas, none of this is useful to me unless it's compatible with at least the most recent version of Windows 10: very few of my customers are running Windows 11, and I suspect many won't upgrade until Windows 10 is no longer supported (optimistically; as of last year, I was still getting occasional support requests from customers running older versions of our software on Windows Server 2003 R2).
[2] https://learn.microsoft.com/en-us/windows/msix/supported-pla...
Even a janky port of RPM or DPKG or OCI with cgroups would have been a better way to move forward. But because MS doesn't have the tools, the ecosystem or the willpower to drop legacy methods and create a proper self-hosting toolbox OS they will never get there.
"Enterprise Development" is the antithesis of successful packaging. Even Apple's half-assed PAX+Shellscripts method (.pkg) is decades ahead of whatever MS keeps pulling out of their hat.
Windows is in maintenance mode. Nothing new and substantial they create will ever get to a working state, they just don't have the resources. I have given up.
[0]: https://github.com/microsoft/microsoft-ui-xaml/issues/8141
Imagine one day having a proper permissions system on windows and NOT having to worry whether that fancy calculator you downloaded is going to compromise your computer or whether a rce bug in CS:GO is going to steal your credit card information from the browser.
I've been looking around the repo, but I see no mention of whether and how this works with programs that need GPU access.
I don't know how this tech works but I feel like we could have had this already using the tech I described above.
As long as it's function is to keep the program locked in, and not the user locked out from modifying it...
There is nothing "magical" about web browsers in that regard.
I didn’t say there was anything “magical” about browsers. They have a sandbox for JavaScript, by default. Windows doesn’t have a sandbox for native apps, by default.
A parent poster seemed to be making a statement of equivalency between running a native application in Windows and running JavaScript in a browser. I don’t think they’re equivalent.
That’s what I’m saying.
You can find exploits on gh for older chromium versions easily
To some extent that's just laziness, because who cares for the long tail of workflows, right, and to some extent unfortunately it's a fundamental trade-off of sandboxing (the OS can't know the details of each and every file format and which files are related and need to be opened together even if the user only launched one file, the application developer does know, but is the untrusted party; being able to paste a file path directly into a GUI respectively directly edit it there can be comfortable, but it bypasses the official secure OS file picker, so again a no-go, etc. etc.).
Does it, by default? https://developer.apple.com/documentation/security/app_sandb... [1] doesn't look like it, and there seem to be special features for requesting access to related files which wouldn't be necessary if selecting a file gave you access to the whole directory. Though I've got no Mac, so no idea how this actually works in practice – maybe you're right, though it'd also noticeably weaken the sandbox, which seems strange.
> I'm curious what you mean by customized UX around file I/O?
Simply things like a directory tree control integrated into the UI, IrfanView's directory switcher (when you reach the start or end of a directory while browsing through your pictures, it pops up a dialogue that allows you to easily – and without having to use the mouse – navigate up and down the directory tree to a different folder), or even something as simple text input control that allows direct editing instead of always having to go via an official OS file picker.
[1] It seems like Apple does have some support for storing relative file references after all ("document-scoped bookmarks"), so that picking something like a master project file also gives access to all related documents, no matter how complex the file format is, though I have no idea whether those really work even when moving files between different devices, and they almost certainly won't work for cross-platform file formats, because non-Mac software will of course have no idea about that kind of thing. And last time I looked, Android's and Windows's sandbox implementation didn't have anything comparable, and Linux likely doesn't, either…
My guess is that their security folks aren't convinced by the robustness of the sandbox and don't want the pain of trying to defend it, which is a pity (for them), because it just throttles their own platform and pushes people towards the web. The browser guys apparently can define a sandboxable platform: why can't Apple?
Re: custom file browsers. Yes, that's a good point. I think you can request access to whole parts of the file tree though even when sandboxed. You have to mark them as exceptions via entitlements and it's automatically granted. Because Apple see the sandbox as a way to mitigate exploits and not allow execution of untrusted code, that sort of approach works fine.
IIRC, it used a filesystem driver shim that rerouted all FS writes during installation into an overlay filesystem image; and then generated a self-unpacking executable, embedding that overlay image, that unpacked the core EXE and spawned it shimmed to read from the overlay image.
What did Windows 10X do that was different than that?
From a quick web search, VAIL was supposed to only be used as a fallback for when RAIL (i.e. a cloud streaming service for your Win32 apps) wasn’t available. So I assume it didn’t necessarily have to be “good” — it was the “safe mode” of Win32 compatibility, per se. It just had to be there as a rare last resort.
But was RAIL any good? Did it even get built?
a lot of things work just fine and are still failures from the management's point-of-view
Microsoft has yet to come up with something even half as useful and popular. So far their best effort has been WSL2, and it's working well because it's linux, not because it's windows containers (which is something else).
This is pretty frustrating because they have plenty of money and smart people to throw at it, yet at every turn we get something that just doesn't match what people want and need, instead we get something that might look good on a keynote slide.
NT also had multiple personalities or subsystems before KVM or QEMU were even thought of, yet here we are, a useless feature with no traction and no ecosystem.
The point isn't the features that a thing like cgroups provides, it's the adoption, and that is something you cannot enterprise your way into like you can with desktop software like office.
If you reverse the statement: why is the Job API not used with OCI, Windows Containers or WSL, and was a replacement created (twice no less, WSL1 and WSL2 are very different) and a virtual machine with linux the only real adopted method for containers.
(answer: because everything else that was attempted just failed one way or another, regardless of de academic or enterprise-ish correctness of those attempts)
https://learn.microsoft.com/en-us/virtualization/windowscont...
Maybe if there was some ProjFS-style text I/O for the Job API someone would have made a OCI-like container format, but I suppose even then it would be too different to be embraced like Docker was when it was released. You'd need to have it combined with WinFsp or a FUSE-alike adapter and it might even be possible to have layers and use a union/merge/overlay FS. Putting that side-by-side with containerd and cgroups2, it would still look rather Frankenstein-ish; not very windows-y, and not linux-ish either.
- They're zips (sorta, but you can't make them with any existing zip library)
- They can contain VFS overlays for system directories. Files placed inside the package under the VFS directory will appear at runtime as if they are installed to c:\Windows\System32 and other well known locations, but only for apps within that package. This is built using an equivalent of unionfs called bindflt.
- Apps run inside "app containers" which are at the lower levels composed of job objects and other kernel features. App containers are the basis of all sandboxing on Windows and are the closest equivalent of cgroups.
- Writes to the user's home directory are transparently redirected to a separate directory specific to that package. This allows data to be cleaned on uninstall.
- You can express various integration points in a declarative manifest file, install/uninstall/download them from the CLI, and individual packages have update feeds a bit like a Docker repository.
There are some differences:
- MSIX is designed for desktop apps, not servers.
- There's no concept of layering like Docker has.
- A Docker repository is a relatively heavy serverish thing. MSIX packages can have a stream of updates expressed, but it's done by just publishing an XML file to a web server.
- MSIX doesn't try to wrap an entire Windows userland in the same way that Docker images ship entire copies of Linux userland. It's all about overlay filesystems.
It's technically a correct format, but that's not what you need to get a thriving ecosystem.
Again, it doesn't matter how correct it is, what features it does have or how it compares to all the other attempts from the past, what matters is that unless a developer is in the single scenario where they are forced to use it, they will probably ignore it.
Granted, before we got into the 'microsoft container concepts suck' threat, this article was specifically about win32 app isolation, so if we look at it from that perspective, this is a step up. But that's not where the mindshare or the money is.
You can then either switch to macOS or ChromeOS with similar models already, use one of the mobile OSes, which have used such restrictions for years, or maybe it is finally when the exodus to Linux Desktop takes place.
Windows workloads are getting smaller, not bigger.
This attempt at a yet another microsft iteration of things like flatpak/docker/dpkg/rpm/nix etc is no more likely to be embraced than the previous ones. There is a reason default packaging of popular software is still SFX packages spewing files all over the place and not MSI or MSIX. The former is usually only included als an alternative (i.e. Chrome's "Enterprise" version) because tools like SCCM are not very useful without it.
This has to do with Microsoft trying to re-invent the wheel time after time, and consistently failing (within their own ecosystem) because they build things that contradict the desired user experience which prevents adoption. And with adoption, I mean the same kind of adoption that Docker (now OCI) has.
That is not a direct link between desktop-app sandboxing vs. microservice containers, but a comparison between doing things good enough for mass usage (Docker) vs. trying to do it 'the enterprise way' (every attempt beyond win32 so far, including COM, MSI and APPX). And it's not about their technology having bugs either (every tech does, not just MS-tech), plenty of the technical aspects are fine, but that alone is not going to drive adoption as the last few decades have shown.
This is just the first step of the roadmap that was discussed at the conference.
Developer certificates are also coming, just like on macOS.
All security knobs enabled by default, no longer opt-in.
No developer certificate, no Windows app.
Again, all, security, knobs, turned,on, by, default.