[HN Gopher] Win32 App Isolation
___________________________________________________________________
Win32 App Isolation
Author : pjmlp
Score : 72 points
Date : 2023-05-24 16:02 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| londons_explore wrote:
| Is this microsoft-docker for GUI apps?
| oneplane wrote:
| 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.
| pjmlp wrote:
| Windows has had cgroups before they were even an idea on
| Linux via Job API.
| oneplane wrote:
| That's the problem, the Job API is not cgroups and cannot
| be used as cgroups.
|
| 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)
| no_time wrote:
| 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...
| pwg wrote:
| 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.
| iggldiggl wrote:
| 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.).
| CamperBob2 wrote:
| What exactly does it do for me as a user?
| criddell wrote:
| 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.
| CamperBob2 wrote:
| I see, it lets me install random .EXEs from sketchy web
| sites on my Windows machine without having to worry. Sounds
| safe.
| iknowstuff wrote:
| Whats your point? You just ran a bunch of untrusted code
| when you visitied this website.
| parl_match wrote:
| Running a native binary in an environment with a large
| attack space and user level permissions is not NEARLY the
| same as running javascript in a browser with all of its
| sandboxing, isolation, and controls. And you know it.
| EvanAnderson wrote:
| Untrusted code running in a well-defined and maintained
| sandbox.
| johnd223 wrote:
| [dead]
| [deleted]
| gjsman-1000 wrote:
| 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...
| oneplane wrote:
| 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.
| wvenable wrote:
| If Microsoft would make it easy and free to package apps (and
| without combining it with sandboxes) all developers would do
| it.
| gjsman-1000 wrote:
| 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._
| OkGoDoIt wrote:
| Exactly my experience with Microsoft development. Since
| 2011 I've gone from working at Microsoft on Windows Phone
| full time to mostly leaving the tech industry and running a
| theater, largely because I bet on the Microsoft horse and
| it turns out that was a losing bet for exactly these
| reasons. I stopped trying to keep up, because what's the
| point? When I do still make programs using C#, they are
| generally command line or Windows Forms, and intended for
| my personal use.
| batty_alex wrote:
| Thank you for summarizing why I left Windows app
| development and haven't looked back
| [deleted]
| pjmlp wrote:
| You missed .NET Native and screwing devs replacing C++/CX
| with C++/WinRT, the return to ATL roots, editing IDL files
| without VS tooling and manually merging generated C++ code.
|
| But hey, from all the warts, and screw-ups, the other
| gardens aren't much better.
| mey wrote:
| Everytime I ponder getting into Windows desktop development
| I see a portion of this picture, think about doing all this
| in Java instead, then remember that that is its own UI mess
| (although overall less storied but worse functionality
| wise), then think Electron would be better, try to get
| Typescript and Vue.js to play nice in Electron, run for the
| hills, briefly consider if building a desktop UI in Unreal
| or Unity would be the easiest, then just go back to playing
| video games.
|
| Edit: Thank you for giving such a nice summary of the
| current landscape of UI dev in Windows native development.
| mike_hearn wrote:
| JVM UI isn't so bad. I've written some pretty modern
| looking UI with it. The sophisticated controls are all
| there.
|
| 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.
| derefr wrote:
| You know how Electron allows you to spawn a native
| backend server as a subprocess, to generate the pages
| that the Electron frontend interacts with? And how this
| means that you can write 90% of your program in some
| native language, and just do a thin UI in JS?
|
| 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.)
| toast0 wrote:
| If you want to do windows desktop development, just find
| the oldest technique that still works and use that. I
| think you can probably still find pre-.net visual studio
| out there and use it, and it'll work. You'll miss out on
| some stuff, but oh well? If you get to the point where
| you have thousands of people hounding you about high dpi
| support, you've made it.
| wvenable wrote:
| Most developers completely ignored everything Microsoft
| had to offer since Windows 7 and because Microsoft is
| Microsoft all their technologies continue to work and
| keep getting updated.
|
| I, for one, never stopped developing in WPF.
| hammyhavoc wrote:
| This sums it up perfectly. It's fatiguing.
| winphone1974 wrote:
| It's also (at least partially) intentional. Microsoft
| keeps you so busy on the treadmill you don't stop to ask
| "wait, should we be doing this?"
| wvenable wrote:
| Microsoft's goals and 3rd party developer goals stopped
| being aligned and it's taken just about this long for
| them to realize that it isn't going to work.
| bashmelek wrote:
| I can't speak for professional development, but for hobby
| projects I personally had a lot of fun with WinAPI and GDI.
| SDL is good too. The churn of everything you mentioned was
| too much for me and it's comforting playing with something
| that isn't going anywhere for better or worse.
| kitsunesoba wrote:
| And to top it all off, even WPF has quirks. I can tell
| which apps on my Windows gaming tower are built with it
| because for some reason the framerate on my cursor drops to
| 60FPS or below on my 240hz monitor when it's within the
| bounds of a WPF window.
| rstat1 wrote:
| That's the power of the horribly unoptimized DX9-based
| renderer WPF was (is still?) built on.
|
| Worst part of WPF for me was the tooling that crashed
| whenever you so much as looked at it wrong.
| rizky05 wrote:
| [dead]
| alkonaut wrote:
| 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.
| EvanAnderson wrote:
| Their own internal developers don't do it, so why would ISV's?
| 8K832d7tNmiQ wrote:
| Is this based on a similar technology that once shown on windows
| 10X years ago?
| gjsman-1000 wrote:
| 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.
| derefr wrote:
| 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?
| gjsman-1000 wrote:
| They attempted to abuse/reuse a in-house technology called
| VAIL. There were not just some compatibility issues; but
| battery life and performance were just bad.
| jcelerier wrote:
| > worked just fine. (I used it myself.)
|
| a lot of things work just fine and are still failures from
| the management's point-of-view
| mike_hearn wrote:
| 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.
| pjmlp wrote:
| 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
| derefr wrote:
| > 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_hearn wrote:
| 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.
| derefr wrote:
| I mean, from what you said, "the installer" isn't your
| product, no? The build system is your product. The custom
| installer that the build tool emits is just something you
| had to create as a workaround because the Microsoft one
| sucks, and which is a pure cost center for you, and one
| redundant to Microsoft's own efforts.
|
| 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?
| mike_hearn wrote:
| The product is "desktop app distribution as easy as for a
| web app" and encompasses whatever's required to do that.
| It's not just the custom installer, there are workarounds
| for Windows bugs in a variety of different places in the
| product and in some modes the installer is integrated
| with the package contents, so it requires the two to be
| co-built.
| Dork1234 wrote:
| 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.
| orra wrote:
| 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?
| withinrafael wrote:
| 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").
| pjmlp wrote:
| I wouldn't call WinUI 3 a success.
|
| What is new here, is that this is the continuation to make all
| Win32 apps sandboxed.
| mike_hearn wrote:
| 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 wrote:
| 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...
| mike_hearn wrote:
| There are different kinds of app containers. The low level
| container tech doesn't care what high level APIs you use,
| it just blocks or redirects stuff, but if you want things
| like file brokering, implicit grants based on powerboxes
| and stuff like that then it wasn't previously available.
| That's what this project is adding to Windows.
|
| 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.
___________________________________________________________________
(page generated 2023-05-24 23:01 UTC)