建议改进 Windows ACL 沙箱：避免持久 Low 标签影响工作区和构建产物

[XJfyrh]

建议改进 Windows ACL 沙箱：避免持久 Low 标签影响工作区和构建产物

在 Windows 上使用 DeepSeek Harness Desktop 0.2.1-rc.2 时，我注意到 Windows ACL 沙箱会给真实工作区设置可继承的 Low 完整性标签，并在会话结束后保留。

理解这个设计的动机：降低子进程完整性，配合工作区标签限制写入和删除，同时通过保留授权避免反复遍历大型目录树。但对日常开发工作区而言，这个取舍带来的影响超出了 DSH 会话，建议重新评估默认策略。

本机只读检查结果如下：

E:\             未显示完整性标签
E:\dev          未显示完整性标签
E:\dev\tools    Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

E:\dev\tools 还存在能力 SID 授权及 Everyone:(CI)(DENY)(DC)。Low 标签是工作区自身的显式设置，并非继承自上述父目录。

主要问题有：

• 构建产物会继承标签。 工作区中的 .exe 被标记为 Low 后，即使从 DSH 外正常启动，其进程完整性仍可能受到文件标签影响。这会改变程序的运行行为，对桌面程序开发尤其不直观。
• 权限修改持续存在。 退出 DSH 或切换到 danger-full-access 不会撤销已有标签；只要目录标签保留，删除产物后重新编译仍会继承。
• 影响其他进程的访问边界。 其他以同一用户身份运行的 Low 完整性进程，在 DACL 允许时，也能修改这棵原本受 Medium 完整性保护的目录树。
• 发现与恢复成本较高。 用户很难从普通使用流程中意识到工作区安全描述符已被持久修改。现有诊断 skill 也明确不恢复完整性标签，无法解决 Low 可执行文件在 DSH 外运行的问题。

建议优先补齐以下能力：

1. 启用前明确告知。 说明修改范围、继承行为、退出后是否保留，以及对可执行产物和其他 Low 进程的影响，让用户明确选择是否接受持久修改。
2. 提供工作区状态入口。 例如 workspace status，显示完整性标签、显式与继承来源、DSH 添加的权限项，以及残留修改。
3. 提供有备份、可验证的恢复工具。 首次修改前保存必要的安全描述符信息；恢复时检查活跃沙箱，精确处理 DSH 的修改，保留用户及其他工具原有权限。
4. 定义构建产物的导出流程。 对用户选定的产物，提供按目标目录安全策略导出的明确操作，并验证最终标签，避免工作区隔离属性意外成为发布属性。
5. 评估影响范围更小的默认方案。 例如受控执行目录、独立工作副本或宿主代理写入，同时说明性能与同步成本。
6. 在权限界面直接说明能力边界。 当前后端主要限制写入和删除，读取及网络访问不在其约束范围内；建议让这些信息在选择权限模式时即可看到。

最希望改善的是：工作区权限变更应当可见、可管理、可恢复，构建产物离开 DSH 后的运行行为也应当可预测。

参考：[Windows ACL 沙箱说明](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/sandbox/sandbox-windows-acl/README.md)、[[微软完整性控制与进程创建规则](https://learn.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control)](https://learn.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control)。

[leolee9086]

go和rust同样遇到了这个问题,反复排查之后才发现是完整性标签的问题,使用完全权限在沙箱外部构建才弄好

[CitrusAqua]

比较大的C++ sln下跑一遍/setintegritylevel修复要一个多小时，而且跑完了也不一定能恢复。至少我刚才跑完一遍还是没修好。
这种bug基本等于永久破坏掉我一个大型项目目录了。