Win32 App Isolation

https://github.com/microsoft/win32-app-isolation

by pjmlp • 3 years ago

117 89 3 years ago

Yay, it's the latest attempt at Project Centennial!

(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...

wvenable3• 3 years ago

If Microsoft would make it easy and free to package apps (and without combining it with sandboxes) all developers would do it.

gjsman-10004• 3 years ago

I really doubt that at this point. Developers have learned that everything Microsoft says to do for Windows, since 2012, will be garbage within a few years. Guaranteed.

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.

alkonaut• 3 years ago

It's a black art (e.g. Windows Installer). But these days using open tools it's not so bad. A desktop app can be built early with only free microsoft tools and really well packaged with free non-microsoft (ok microsoft-adjacent) tools like Squirrel. That wouldn't make them isolated in the sense of store apps, however.

EvanAnderson5• 3 years ago

Their own internal developers don't do it, so why would ISV's?

oneplane9• 3 years ago

I think they are getting bit by their wishes to make it both perfect and backwards compatible at the same time.

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.

mastax• 3 years ago

I have spent weeks of my life trying to get windows packaging to work. Twice with APPX, twice with MSIX. Mostly with greenfield C# apps, sometimes with existing WPF apps. Every year I think: surely it'll work now, they just published another blog post touting the new features? No. Every time I run into something that's not documented how to be done, something that's not implemented, or something that's broken, often with a detailed bug report that nobody at Microsoft has bothered responding to (e.g. [0] one of many).

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

lostmsu• 3 years ago

There are quite a few packaged apps in the store. I personally made 2.

8K832d7tNmiQ• 3 years ago

Is this based on a similar technology that once shown on windows 10X years ago?

gjsman-10004• 3 years ago

Windows 10X was a re-architecture of Windows, and because developers weren't repackaging their apps, 10X was trying to figure out how to automatically package apps from unpackaged installers, and run them with compatibility for old Windows without affecting the modern 10X architectural design. It was not successful.

derefr5• 3 years ago

It's odd that it failed; https://en.wikipedia.org/wiki/VMware_ThinApp was doing this literally 20 years ago and worked just fine. (I used it myself.)

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?

orra2• 3 years ago

Windows 8 and UWP weren't ever popular, but Microsoft is having a little more success parcelling up UWP:

* .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?

mike_hearn11• 3 years ago

The new stuff are basically new package (msix) capabilities that trigger new codepaths in classical Win32 APIs. Microsoft's previous app sandbox required the use of WinRT APIs that not many people have adopted.

Avery3R• 3 years ago

AppContainers have supported win32 from the start, not just WinRT.

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...

pjmlp8• 3 years ago

I wouldn't call WinUI 3 a success.

What is new here, is that this is the continuation to make all Win32 apps sandboxed.

orra2• 3 years ago

I wouldn't call WinUI 3 a success.

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.

withinrafael• 3 years ago

You are correct that Win32 apps were already supported in AppContainer. What's new here is that a handful of Win32 APIs are now slowly getting plumbed into the capability system. This means Win32 apps that currently ship packaged as needing "full trust" can, if supported, reduce the requested capabilities to those that are supported by Win32 App Isolation (e.g., "system tray access").

no_time• 3 years ago

This is objectively great news.

As long as it's function is to keep the program locked in, and not the user locked out from modifying it...

CamperBob22• 3 years ago

What exactly does it do for me as a user?

criddell• 3 years ago

It’s a security boundary. It lets you control the resources an application has access to. For example, if that cool weather app you just installed asks for access to your Documents directory, or your camera or microphone, you can say no.

pwg• 3 years ago

Indeed, but sadly, features designed to "keep the program locked in" can also often be miss-used to "keep thee user locked out". Only time will tell where this one goes.

iggldiggl2• 3 years ago

And all the file sandboxing approaches I've seen so far only seem to cater for the simple "choose a single file (or directory)" workflow and break multi-file formats, any customised UX around file I/O and any other advanced workflows.

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.).

mike_hearn11• 3 years ago

This feature depends on MSIX. My company makes Conveyor which amongst other things generates/signs MSIX files without using Microsoft's toolchain so you can ship apps from your developer laptop or Linux CI. As almost all modern/maintained Win32 apps are actually built on cross platform frameworks, being able to cross-build packages using a tool that understands Electron/JVM/Flutter build system config is quite convenient. By this point my guess is that we have more experience with MSIX in the wild than many of Microsoft's own teams do.

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.

derefr5• 3 years ago

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?

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?

mike_hearn11• 3 years ago

If Microsoft wants to offer to buy the company they can email me about it, otherwise, no. It's a small firm without venture funding so we can't just open source our product.

pjmlp8• 3 years ago

This is the continuation of bringing UWP security model into Win32, and make Windows security features all enabled by default.

See BlueHat IL talk on the matter,

https://youtu.be/8T6ClX-y2AE

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.

https://youtu.be/w6VwHGPz12w

ripley122• 3 years ago

These are really good questions. I've never used Conveyor, but hoo boy I've run into a lot of the same problems with MSIX.

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.

mike_hearn11• 3 years ago

We've got it pretty stable now, but it's taken a lot of effort. There are a few cases where Win32 changes its behavior if you're packaged, but that's unfortunately the case on every OS. Some Apple APIs work differently if you're in bundle context too, also depending on whether the app is signed.

viraptor• 3 years ago

because you'll quickly hit bugs that Microsoft know about but never backported the fixes for.

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...

londons_explore• 3 years ago

Is this microsoft-docker for GUI apps?

oneplane9• 3 years ago

More like yet another half-assed attempt at cgroups. Not saying cgroups is chopped liver, but at least it has in broad use with lots of users, tools and experience over a long period of time.

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.

pjmlp8• 3 years ago

Windows has had cgroups before they were even an idea on Linux via Job API.

Dork1234• 3 years ago

So what does this mean for developers writing software plugins or inter opts for other applications. Seems like more of a mess for developers to deal with.

pdntspa• 3 years ago

So I have this mod manager for Elder Scrolls: Oblivion that sets up a virtual filesystem as an overlay over the game's original directory structure, and then launches the game in a way that makes the game see the overlay as if they were the original files. I am very impressed at what seems like outright computer voodoo, I had no idea Windows had those kinds of APIs or that kind of capability.

I don't know how this tech works but I feel like we could have had this already using the tech I described above.

int_19h2• 3 years ago

Filesystem (and registry) redirection has been around in Windows for a while, and is used to e.g. make sure that pre-Vista apps still run if they do things like trying to write to "Program Files". But that all assumes that the app is not adversarial - proper sandboxing is a different story.

mmozeiko• 3 years ago

I'm pretty sure such thing is implemented by hooking OS functions that are dealing with directory enumeration, create/open file, etc - and then redirecting to custom code that provides virtual files & their contents. There's no standard Windows API for that, aside writing custom driver. But hooking such functions is relatively straight forward process because they are imported from well known shared libraries - you just need to make sure you hook all the functions that are relevant to filesystem operations.

andersa• 3 years ago

Wow I've been waiting for this for so long. This is literally my #1 most requested windows feature.

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.

Win32 App Isolation

Related Stories