[Bug]: Required manifest changes are not compatible with Windows Application Packaging Project

[riverar]

Version

Windows vNext: 25375.1
Win32 App Isolation: 0.1.0
Developer mode enabled

Repro Steps

1. git clone https://github.com/File-New-Project/EarTrumpet
2. Edit EarTrumpet\EarTrumpet.Package\Package.appxmanifest per Win32 App Isolation documentation
3. Attempt to build/deploy using the Windows Application Packaging Project (wapproj)
4. Observe one or more of the errors below

Unexpected Results

# With TrustLevel specified
Error APPX0501 Validation error. error 80080204: App manifest validation error: Line 23, Column 6,
Reason: The EntryPoint value "Windows.FullTrustApplication" must declare attribute "TrustLevel" with value "mediumIL".

# Without Executable specified
Error APPX0501 Validation error. error 80080204: App manifest validation error: Line 23, Column 34,
Reason: The attribute EntryPoint must be specified if the attribute Executable on the Application element is specified.

# Without RunFullTrust specified
Error APPX0501 Validation error. error 80080204: App manifest validation error: Line 35, Column 10, Reason: The element specified requires "runFullTrust" capability.

[tiangao-ms]

I don't believe you can use any existing packaging process to package isolated Win32 app. This is a very new feature and requires special packaging tools(like we mentioned in the docs). You need to download the special version of MPT from our release and edit the manifest manually as of now. We will try to improve the process in the future, but for now that's the only way that works.

[riverar]

It seems Win32 App Isolation requires breaking the rules and constraints of the existing/old appx schemas, making it impossible to light up on supported operating systems. I am eager to hear how you envision app developers, with one app, will target across Windows 10, Windows 11, and Windows 11 w/ Silo support.

[tiangao-ms]

Could you elaborate on the rules/constraints Win32 app isolation breaks? There are definitely things in the manifest that need to be changed.

Win32 app isolation requires OS support so by definition, it can't work on old OS versions (that do not have the support). We are in public preview phase now and for every product that requires OS support, there will be a transition phase when we can't support every single platform.

We would like to provide a detailed guidance for devs to isolate their apps so they can spend a very minimum amount of time to create the isolated version of their app(in our experience, probably hours in the first time, minutes once they are familiar with the process). Yes, there will be a period of time when isolated app can't cover all the ground, but the percentage of supported version is increasing in the market and there will be a day when most of the customers will have the supported OS. (There are still Win XP users so it's not always possible to cover everyone).

[riverar]

Consider the error I listed above.

Error APPX0501 Validation error. error 80080204: App manifest validation error: Line 23, Column 6,
Reason: The EntryPoint value "Windows.FullTrustApplication" must declare attribute "TrustLevel" with value "mediumIL".

My app has ~6 million users across Windows 10 and Windows 11. I can't change the trust level to appContainer until all these OSes become EOL in ~10 years or so. So it seems like the plan forward here is that I have is to ship a completely separate app package?

Would be great if we could opt-in to the silo with a graceful degrade experience for unsupported OSes.

[sylveon]

I'm in the same boat, with a bunch of Windows 10 users. My envisioned plan would be a single package, that when ran on Windows 11 SV2 or older (including W10), falls back to full trust. On supported operating systems, it would use AppSilo.

[cchavez-msft]

Consider the error I listed above.

Error APPX0501 Validation error. error 80080204: App manifest validation error: Line 23, Column 6,
Reason: The EntryPoint value "Windows.FullTrustApplication" must declare attribute "TrustLevel" with value "mediumIL".

My app has ~6 million users across Windows 10 and Windows 11. I can't change the trust level to appContainer until all these OSes become EOL in ~10 years or so. So it seems like the plan forward here is that I have is to ship a completely separate app package?

Would be great if we could opt-in to the silo with a graceful degrade experience for unsupported OSes.

Thank you so much for your input, riverar. We wanted to let you know that we will be working on a solution.

[HotCakeX]

until all these OSes become EOL in ~10 years or so. So it seems like the plan forward here is that I have is to ship a completely separate app package?

Windows 10 will reach EOL in 2 years, 2025.

Since win32-app-isolation is a security feature and security is achieved with multiple layers, it won't be logical to use unsupported OS that lacks most recent updates and security features.

win32-app-isolation also works with Smart App Control which is only available in Windows 11 22H2 and later versions.

[riverar]

@HotCakeX Our app has users across Windows 10, Windows 10 LTSC, Windows 10 Enterprise, and all releases and SKUs of Windows 11. If we were to change our manifest to only support Win32 App Isolation, we would have wait for all those OS versions to flush out. For example, support for Windows 10 Enterprise LTSC 2019 ends Jan 9, 2029.

But yes, if we were to slice off the outliers, we could perhaps reduce that wait to ~3-5 years, assuming Win32 App Control lands in Windows vNext on time. (It does not appear Win32 App Control is going to be in the next Windows 11 23H2 update.) There's no way I'll remember to revisit this in ~3-5 years.

[HotCakeX]

@riverar
What if app developers who have substantial users on LTSC version of OS kept a separate installer just for them so that the advance of security and technology wouldn't hinder their work and they can maintain both user bases without sacrificing security.

The older user base won't be using win32-app-isolation simply because the underlying features don't exist on those old OS versions and the new user base will be using win32-app-isolation and utilize the new security features in new OS versions.

Do you think that's a good solution?

Windows is known to be super backward compatible and even though it might help a few people, it's hurting security a lot. A lot of security features are turned off by default because of this. A lot of old stuff is still bundled with the newest version of the OS to support backward compatibility. I've seen people run 20 years old software on the newest OS version, this might be cool but shouldn't happen. All the old components in Windows, TLS 1.1, 1.0, SSL protocols, all the insecure cipher suites, SHA1 ,MD5 hash algo etc. etc.

At some point Microsoft should draw a hard line, just like they did with Windows 11 hardware requirement, and be strict about it.

Just like mobile OSes, Store apps, Apple's ecosystem, Microsoft should also enforce signed programs only. This can improve security so much and make it easier for security solutions to properly identify and allow/block apps and programs on Windows.

MSIX format must also be enforced by the time Windows 12 comes out. No more homebewed installers. When user uninstalls an app, everything should be removed without any leftover, that's what MSIX guarantees.

Today, Security is so much more important than productivity. The majority of companies either don't know how to secure their stuff or intentionally use insecure stuff and are OK to pay financial penalties when they get hacked and keep their insecure infra.

These are all nothing but facts and what we're seeing in the real world all the time.

[riverar]

@HotCakeX

Do you think that's a good solution?

No. Creating/maintaining two separate packages is not going to happen. Doing so would require changing/duplicating all the infrastructure needed to deploy and creates new challenges (e.g., dev dashboard metrics, data migration, winget package name, store confusion, add-ons, etc.)

From the responses above, it sounds like Microsoft has acknowledged the problem so I look forward to seeing what they come up with.

[hj-collab]

@HotCakeX There is no hope for Windows 11 unless they can enforce this Win32 sandboxing. I think that might not be possible with so many packaging formats and legacy stuff to support. The primary reason for high windows market share is backward compatibility. If you kill it then Windows will lose market share.

I have moved from a standard user account based Windows 11 with WDAC policy to OpenSUSE MicroOS Aeon. I love the fact it's immutable and applications are isolated via Flatpak. Flatpak sandboxing is not very well secured but still offers decent protection and runs the application as rootless. I use containers for rest of the stuff. It isolates them from the core and I don't need them to be running every time. Containers may not be as secured as a VM but offers decent protection with hardly any extra resource usage.

MicroOS has more SELINUX policies compared to any other Linux distro iirc. It stays updated every day with latest stuff fixing many unknown/uncategorized vulnerabilities. I have my eyes on upcoming Ubuntu Core Desktop 24.04 too. It might set a new standard for desktop security.

I plan to shift to chromebook and chromeOS in the future. I don't believe Windows will be able to fix the security mess in the current decade. I don't think just focusing on Anti Exploit is enough when the core is not immutable at all and applications developer find it tedious to publish their app in the MS Store.

Edit: This feature does not support any other packaging formats than MSIX. Majority of developers won't be interested to use this. Dead on Arrival.

[hj-collab]

@HotCakeX I am using WDAC since 2020. I have seen your repo. I am taking benefit of most of these features via a powershell script which runs after first boot on any windows install I do. It is my own script customized for my needs.

My WDAC policy is pretty simple that is allow signed MS apps + 4 to 5 devs which I trust. It is a default deny policy with few certs trusted. I don't trust ISG at all as I have been able to bypass it multiple times in the past and also the fact Smart App Control trust all binaries if it trust the provider. I had to ask the devs to sign all binaries in their application which I am using. But now that they have signed those binaries my policy is very small with no files whitelisted.

But again WDAC or any other Windows security does not ensure immutability and sandboxed only apps. Windows 10S was trying to achieve that. But it got poor dev response. Same as this feature is going to get.

Just focusing on Anti Exploit is not enough. Windows should work on fixing the core. Immutable OS + Mandatory Sandboxing + single app packaging format + single delivery source.

I believe some of the Linux distro are much closer to solve this problem than Windows. They have immutable core (ChromeOS, OpenSuse MicroOS, Fedora Silverblue, SteamOS, Ubuntu Core, etc), they are focussing on one packaging format (android apps / flatpak / snap) and with sandboxing.

Ubuntu Core and ChromeOS does not support any other packaging format. OpenSuse MicroOS, Silverblue and SteamOS allows modifying the core manually but that will also stop once the flatpak support is there for most apps. It is increasing day by day and it might be the only packaging format available for linux and non ubuntu / chromeos. Chrome OS might be the most superior desktop OS right now as dm-verity also helps. MicroOS is also working on remote attestation but I am yet to test it out.

MS Store sucks in comparison. So many duplicate and malicious apps lurks there. I had to report more than 10 fake WinSCP apps from the store. I believe some of them are banned now. But new keeps showing up. Comparatively Flathub and Snap Store have much stricter vetting process.

I can bet that these Distro will solve the above problem much before Windows will. Linux security is improving with time. Wayland & Pipewire are much more secure than their predecessors. Linux kernel have added rust support and we might see rewriting large parts of the code to this memory safe language. MS have also started working on rust in Windows kernel as per their announcement. Even these larges companies are working to improve Linux Kernel. We might see micro kernels in future or GrapheneOS on desktop before MS solves the security mess of Windows. You were a part of GrapheneOS team iirc. Android desktop mode is also improving so Android might also be a viable option in the future.

MS lacks a vision else this bug report would not have been made in the first place. I want to stick with the OS who are actually solving the fundamental issue and not providing a band aid.

[HotCakeX]

@hj-collab

1. no one is only focusing on anti exploits.
2. Looks like you need to read my repo and check out the new ways we can use WDAC and a lot more.
3. I talked about Windows Sandbox and Hyper-V in my previous comment, that's the proper and safe answer to sandboxing and containerization. Soon I'm planning to create a new repo for Windows Sandbox configs of popular apps which i use myself.

[hj-collab]

@HotCakeX

3. It is not a viable solution imo unless you create separate Hyper-V VMs for each app. Also in case of Windows Sandbox with pre-installed app you will need to download/install app each time the sandbox is open. If you use a portable version of Photoshop from a host folder then are you not exposing a host folder to the Sandbox? I have 3 hyper-v VMs segregated for graphics app, accounting stuff and one for more secure stuff (such as using digital signature to sign invoices, documents, gst filing, company documents, etc).

But I have started moving most of these windows devices to OpenSuse MicroOS and eventually all the hardware will be replaced with ChromeBooks. I am trying to find replacements for some apps or else will keep one hardened Windows device for them.

[HotCakeX]

@HotCakeX

3. It is not a viable solution imo unless you create separate Hyper-V VMs for each app. Also in case of Windows Sandbox with pre-installed app you will need to download/install app each time the sandbox is open. If you use a portable version of Photoshop from a host folder then are you not exposing a host folder to the Sandbox? I have 3 hyper-v VMs segregated for graphics app, accounting stuff and one for more secure stuff (such as using digital signature to sign invoices, documents, gst filing, company documents, etc).

But I have started moving most of these windows devices to OpenSuse MicroOS and eventually all the hardware will be replaced with ChromeBooks. I am trying to find replacements for some apps or else will keep one hardened Windows device for them.

it is viable and much better than anything other OSes provide.

[hj-collab]

@HotCakeX Check KeePassXC latest feature request on Github opened by me. Care to respond there?

[HotCakeX]

@HotCakeX Check KeePassXC latest feature request on Github opened by me. Care to respond there?

Check this repo instead: https://github.com/HotCakeX/Harden-Windows-Security

[sylveon]

Windows 10 will reach EOL in 2 years, 2025.

LTSC goes EoL in 2027, while IoT LTSC only goes EoL in 2032. So Windows 10 still needs to be supported for roughly a decade. Besides, people will keep using EoL operating systems anyways (I sometimes see reports from people trying to run my app on RTM Windows 10, build 10240). Making my users annoyed that the application can't run on their system for safety benefits they don't really see ultimately is a no sell.

[ankofl]

I take it it's still not fixed?

I just need to create an MSIX installer for a project that has several DLLs, but no exe. How can I do this?

[cchavez-msft]

Hello, @riverar , @ankofl , @sylveon.

Thank you so much for checking on this. We have worked on a fix for this issue. Devs can now create a single package (on 26100.2161 build) that runs isolated in supported OSs and falls back to FullTrust on non-supported OSs. Please, let us know your thoughts. We also have a new way to package applications from VS. More info here: https://learn.microsoft.com/en-us/windows/win32/secauthz/app-isolation-overview

[sylveon]

The samples I see in the docs have you set the MinVersion to 26100. This doesn't sound right, the package wouldn't run down level in that case.