检测到论坛CSS可能没有正确加载，如出现排版混乱请刷新重试。

We detected that the CSS might not be loaded correctly. If the website displays abnormally, Please refresh and try again.

浅尝 Win32 App isolation

DaleZ · 2024-02-07T12:33:47+00:00

Win32 App isolation 是微软混合了一些已有技术后打造的一个更无缝的“沙盒”，与之前的技术不同，这个技术不需要在编程级别上进行适配，即使已经成型也可以 msix 化，同时更安全。由于是去年宣布而且还没正式发布，网上没什么体验和评估。但这让我心很痒，要知道如果效果很好的话，国内的一堆软件根本就不是事...

DaleZ

何木槿你需要检查是不是混进去了一些奇奇怪怪的东西。我打包命令提示符的时候还把两个系统服务一起加了进来（（（
有一个专门的页面给你查看扫描到的服务，那时候你就应该检查并移除垃圾。现在估计只能拆包改AppManifest了。

何木槿

DaleZ 我估计是VMware需要注入驱动，但被挡下来了。

DaleZ

何木槿你是否重新启动了？打包工具允许将打包流程保持到重启之后，那样可能可以。
~~实在不行咱还可以打包别的嘛，反正咱都知道 VMware 很安全~~

Baka632

DaleZ 谢谢您的测试！

错误的，我之前的测试有问题。
我跟着 microsoft/win32-app-isolation 这个 GitHub 仓库里面的指引重新创建了应用包，下面才是正确的结果：

左边是打包应用，右边是未打包的。
结果表明：应用确实能够检测到应用是否位于 AppContainer 中，但是仍然不能染指它不应该访问的地方（记得在包清单中移除掉 runFullTrust 权限）。

DaleZ

Baka632 仍然感谢您。既如此，国产软件封锁此功能分分钟的事情。如果不移除程序访问的到吗？
那个软件（我指的是 MSIX Packaging Tool）默认加上完整权限干什么（

Baka632

DaleZ runFullTrust 是 MSIX Packaging Tool 默认添加的权限（）

DaleZ 默认加上完整权限干什么

大概因为 MSIX Packaging Tool 最初并没有想要限制 Win32 应用。

Baka632

DaleZ 如果不移除程序访问的到吗？

不移除 runFullTrust，程序仍然能确定是否处于 AppContainer 中，也仍然不能随意访问其他文件。

不过这里只验证了文件访问，还没有检查注册表等功能的访问情况。

SteveWorkshop

Baka632 不过这里只验证了文件访问

我估计到这一步就行了，app发现无法读取信息直接闪退或者上报环境异常//作弊

Baka632

注意，理论上 Win32 App Isolation 要到 25357 才能使用，不过根据仓库中的这个 Issue，22621 已经支持了部分 Win32 App Isolation 的功能。

我之前的测试都是使用的上面的方法。

另外，Win32 App Isolation 在预览版系统有更完善的功能，请查阅 GitHub 上的文档：msix-packaging-tool 和 release-notes。

我这里在包清单中定义了四个功能：

isolatedWin32-promptForAccess，应用访问未在包清单中允许访问的文件时，会要求用户明确允许。
isolatedWin32-accessToPublisherDirectory，允许访问名称以发布者 ID 结尾的文件夹（原文：Access to directories that end with the publisher ID）
isolatedWin32-dotNetBreadcrumbStore，大概是允许应用访问 .NET 相关的文件
isolatedWin32-userProfileMinimal，大概是允许访问用户文件夹的特定文件

（后两个功能，在文档的描述是："allow minimal access to libraries such as MSVC runtime or other Windows/3rd Party DLLs for applications that don't support prompting"）

在 25931 中测试，出现了文件访问提示：

DaleZ

好的，我发现我也错怪微软了，之前打包的东西都只是基础 msix，没有开启 isolation。因此命令提示符和 QQ 能够正常工作也就可以解释了。
不幸的是，按照微软提供的方法编辑包文件，我无法成功地重新生成包，因此我的浅尝只能到这里了。
这篇主题能够获得精品也有@Baka632的精心尝试，在此表达感谢。
总结一下到目前为止的结论：

按照微软步骤只完成打包部分将会生成普通 msix 包，不带 isolate 功能，提供最基础的注册表和 Appdata 虚拟+重定向写入功能（但可读！！！），也仍然可以调用外部程序或对非敏感文件夹内进行读写。
Win32 App isolation 尚未正式可用，且仅在 Dev/Canary 版本 25357 及以上才能够通过操作系统提供预期的隔离功能。在较低版本上也可使用，但可能仅提供基础 msix 就有的隔离功能或功能不完全。
根据 Github 上的此 issue，可以通过改写为部分不标准的属性来为 Windows 11 22H2 提供 isolation 的部分支持，但不会征求用户对文件的访问权（直接阻止程序，除非对文件访问权限也使用不标准属性），其它功能是否可用尚不可知，尤其是对外部程序的调用权限。
Win32 App isolation 预期行为是阻止敏感操作的未经允许行为，但可以通过修改包文件来默认授予它们权限，或者可能 Windows 会向你要权限（仅在微软官宣支持的版本上弹窗）。尽管如此，isolated App 仍然可以获知自己是否被隔离，那么国产软件完全可以在检测到之后拒绝启动，除非微软以后关闭这个功能。
最开始对是否依赖 Windows App Runtime 1.4 来实现功能的猜测已推翻，因为打包的命令提示符不需要这个。似乎只是加载隔离的 dll 需要此物。

然后就没然后了，这个功能的发展还需要看未来动向（会有坛友对此功能进行持续性跟进吗？）。如果有一天这个技术成了 Windows 应用的强制性要求，那么国产软件最终也不得不妥协，但到时候或许他们已经有别的方法了……

不过话又说回来，从 Windows 整体开发动向和此功能的特性来看，微软内部似乎确实在对 Windows 进行核心级的大变动，不顾费时费力宁可向下移植功能，疯狂进行周期跃进，也不推内核更新，看来是在认真地做大功能、做容器化了。显然这 isolation 与系统内核有着一定程度甚至深度绑定，是轰轰烈烈，还是悄无声息地消失，就看微软了。~~我很看好哦！~~