[Bug] Windows 受限令牌沙箱内 CIM/WMI 整体不可用：Get-CimInstance 及全部 CIM 派生命令（Get-NetTCPConnection / Get-NetIPAddress / Get-NetAdapter / Get-Volume）均返回"拒绝访问"(0x80041003)，Get-PSDrive 静默报 0

[dm11c47333]

前注：自动化过程中发现本问题，我觉得需要发一个report。本人并非专业程序员，可能操作有误，请见谅。本文如有问题，请大家指正。
English abstract：Inside the restricted-token sandbox on Windows, all CIM/WMI access fails with Access denied (0x80041003): Get-CimInstance for any class, and every CIM-backed cmdlet (Get-NetTCPConnection, Get-NetIPAddress, Get-NetAdapter, Get-Volume) reports the same error. Those commands behave correctly — they do raise an error. The real trap is silent wrong values: Get-PSDrive reports 0 for every drive's Used/Free (its usage figures come from a WMI query) while [System.IO.DriveInfo] returns the correct free space at the same moment; likewise the common idiom -ErrorAction SilentlyContinue turns any CIM failure into an empty result, so a caller can conclude "nothing is listening" when the query never ran. Native alternatives are unaffected: netstat -ano, Get-Process, Get-Service, [System.IO.DriveInfo], Get-Counter, and direct registry reads. Request: (1) document the CIM/WMI limitation together with the native substitutes (most valuable for agent/automation authors), (2) ideally allow read-only root/cimv2 queries.

环境

项	值
DSH	桌面版，版本 44.0.0
系统	Windows 10 Pro 22H2，build 19045
外壳	PowerShell 5.1.19041.6456（C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe）
账户	普通用户，非管理员（admin=False）
沙箱	通过 DSH 的沙箱化命令执行（受限令牌）；文件策略 workspace-write（read-only 使用同一受限令牌，预计同样复现，未单独验证）

现象

沙箱内 CIM/WMI 完全不可访问：Get-CimInstance 查询任何 WMI 类都返回 拒绝访问（HRESULT 0x80041003，WBEM_E_ACCESS_DENIED）；所有基于 CIM 的内建命令（CDXML 型，如 NetTCPIP / NetAdapter / Storage 模块）报同一个错误。

受影响 / 不受影响（全部为本机实测）

命令	是否基于 CIM	结果
Get-CimInstance Win32_OperatingSystem	是	拒绝访问
Get-CimInstance Win32_LogicalDisk	是	拒绝访问
Get-CimInstance Win32_ComputerSystem	是	拒绝访问
Get-NetTCPConnection -State Listen	是	拒绝访问
Get-NetIPAddress	是	拒绝访问
Get-NetAdapter	是	拒绝访问
Get-Volume	是	拒绝访问
Get-PSDrive -PSProvider FileSystem	是（用量走 WMI）	不报错，但 Used/Free 全为 0
netstat -ano	否（原生）	正常（列出 4892 / 7880 监听）
Get-Process	否（原生）	正常（22 个进程）
Get-Service	否（SCM）	正常（276 个服务）
[System.IO.DriveInfo]::new('F').AvailableFreeSpace	否（.NET）	正常（174,640,631,808 B ≈ 162.66 GB）
Get-Counter '\Memory\Available MBytes'	否（性能计数器）	正常（29,914 MB）
注册表 HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion	否（原生）	正常（Windows 10 Pro 22H2 / 19045）

最小复现（原始输出见附件日志）

# 1) CIM 直接查询 —— 明确失败
Get-CimInstance Win32_OperatingSystem
#   实测：Get-CimInstance : 拒绝访问
#          HRESULT 0x80041003  (WBEM_E_ACCESS_DENIED)

# 2) CIM 派生命令（NetTCPIP）—— 同样明确失败
Get-NetTCPConnection -State Listen
#   实测：拒绝访问      ← 注意：命令本身是"报错"的，不是静默

# 3) 但加上常见的防御式写法后，失败就"消失"了，只剩空结果
(Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue).Count
#   实测：0            ← 调用方若据此判断，会得出"没有任何端口在监听"的错误结论

# 4) 同样的信息用原生 API 完全正常
netstat -ano | Select-String ':4892|:7880'
#   实测：TCP 127.0.0.1:4892 0.0.0.0:0 LISTENING 12488
#         TCP 127.0.0.1:7880 0.0.0.0:0 LISTENING 38632

补充例证：内建命令直接给出"静默的错误值"（这一例不需要调用方任何写法问题）

Get-PSDrive -PSProvider FileSystem
#   实测：C / D / E / F 四个盘的 Used 与 Free **全部为 0**（没有任何报错）
#   原因推断：PowerShell 5.1 的 Get-PSDrive 取盘符用量走 WMI 查询；
#             CIM 被拒后字段静默回落为 0（而 .NET 路径正常——见下行对照）
[System.IO.DriveInfo]::new('F').AvailableFreeSpace
#   实测：174640631808  (≈ 162.66 GB)   ← 同一台机器、同一时刻，完全正确

这一例与 -ErrorAction 那例的区别很重要：这里命令自己返回了错误答案，调用方毫无察觉。
对自动化/Agent 而言，"某盘剩余 0 GB"可能直接触发清理、迁移等破坏性动作。

为什么值得修（对 Agent / 自动化尤其）

• 失败模式与"空结果"难以区分：-ErrorAction SilentlyContinue 在诊断脚本里几乎是条件反射（避免一行失败刷屏），一旦加上，"CIM 不可用"就变成了"没有监听端口"这类看似正常但完全错误的结论。
• 对 Agent 类调用方，这会直接导致错误的下一步动作（例如误判本地服务未启动而重启/改配置），且没有可观察的失败信号。
• 本项目真实踩到：一度据 Get-NetTCPConnection 的空结果判定"两个本地语音服务都没启动"，而 netstat 显示它们一直正常监听；Get-PSDrive 也曾报出"磁盘剩余 0 GB"。

所以本条不是要求改 Get-NetTCPConnection 的行为（它没错），而是希望把该限制显式文档化——让调用方知道"CIM/WMI 在沙箱内不可用"，从而改用下表的原生替代。

期望行为（按优先级）

1. 文档化（最重要）：在 Windows 沙箱限制说明中写明"CIM/WMI 在沙箱内不可用（0x80041003）"，并附上表"原生替代写法"。对 Agent 集成方价值最大。
2. 可选放行：若可只放行 root/cimv2 的只读查询，代价最小、收益最大（端口 / 磁盘 / 内存这类只读诊断即可恢复）。
3. 可选提示：文档中提示"沙箱内 CIM 类命令在 -ErrorAction SilentlyContinue 下会静默变空、Get-PSDrive 会静默报 0"这两个陷阱（属通用 PowerShell 语义，单独说明即可）。

相关（既有报告：受限令牌裁剪权限的三个侧面）

• #1157 Sandboxed commands lose ALL outbound network access on Windows (ACL restricted token)
• #4163 Windows restricted-token sandbox: Schannel TLS fails with SEC_E_NO_CREDENTIALS
• #997 Windows 沙箱 shell 无法建立任何 TLS/HTTPS 连接（SEC_E_NO_CREDENTIALS）
• #1847 workspace-write sandbox: external processes fail with 0xC0000142 on Windows 10 (build 19041)

上述覆盖"网络 / TLS / 进程创建"；本条补充 CIM/WMI 这一面（整类只读诊断命令不可用，且存在静默错误值），因此单独提出。

附：我这边是怎么绕过去的

服务状态判断全部换成"原生 API ＋ HTTP 健康检查"：

• 端口 → netstat -ano（解析 LISTENING 行）
• 服务是否真的可用 → 直接打它的 /health（比看端口更可靠）
• 进程 / 服务 → Get-Process / Get-Service
• 磁盘 → [System.IO.DriveInfo]
• 内存 → Get-Counter
• 系统版本 → 注册表

这样在沙箱内外结论一致、且不会出现"静默错误值"。
issue草稿-GetNetTCPConnection.md
issue日志-CIM-WMI.txt

[argszero]

Thanks for the careful write-up — the environment table and the affected/unaffected split make this easy to reason about. Your priority ordering is right, and I want to reinforce the part you put first: for an agent caller the silent wrong value is worse than the explicit denial. Get-PSDrive reporting 0 for a drive with 162 GB free, and -ErrorAction SilentlyContinue turning a query that never ran into "nothing is listening", are the two outcomes that produce a confident wrong next action.

Three source-level observations that affect where a mitigation can live.

1. The denial does not arrive on the error channel. A confined PowerShell command runs through the shell tool, whose renderer states its contract explicitly: "Non-zero exits are reported, not errored — the model decides how to react; only infrastructure failures (spawn errors, aborts) surface as isError results" (packages/shell/tool-pwsh/src/render.ts). A CIM access-denied is a non-terminating cmdlet error, so it sets no non-zero exit code either. The denial therefore reaches the caller inside a result the pipeline calls a success, on the stderr channel of the settled foreground value:

{ kind: 'foreground', exitCode: 0, stdout: { text }, stderr: { text: "<the 0x80041003 error record>" }, sandbox: { mode, denied } }

Two consequences. A caller that branches on the tool's error channel never sees it — the text is just output it has to read. And a mitigation that inspects only the failure path misses the common case; it has to read the settled value's stderr.

2. Which layer denies the WMI namespace is not settled, and I would not price the "cheap fix" before it is. The Windows backend creates the confined token as CreateRestrictedToken(..., DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED) and lowers it to Low integrity (packages/sandbox/sandbox-windows-acl/src/token.ts). Its README already records one sibling of your finding — "whoami and token-inspection cmdlets may fail under the restricted token … it is diagnostic noise rather than an operational failure" — and your report adds a second, operational one, which is the more interesting half. But the same README also states that the two access-check passes intersect write-class access only, and that "writes and deletes are restricted; reads, network, and process visibility are not". So whether WBEM_E_ACCESS_DENIED comes from the restricting-SID pass, the Low-integrity mandatory-label check, or the WMI namespace open's own access mask is not decided by the evidence in the report. That distinction decides the cost of your option 2 (allow read-only root/cimv2): if the deny is a pass-2 write-class intersection, a narrowly granted capability SID is plausible; if it is the integrity label or a namespace-level ACL, the same change buys nothing.

3. On ask #1, the substitute table is the right artifact. Your verified pairs are the ones I would keep:

need	CIM-backed (denied)	native substitute
listeners	Get-NetTCPConnection	netstat -ano (parse LISTENING), or hit the service's own health endpoint
volumes	Get-Volume, Get-PSDrive (silently 0)	[System.IO.DriveInfo]::new('<drive>')
memory	CIM memory classes	Get-Counter '\Memory\Available MBytes'
OS build	Win32_OperatingSystem	registry HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion
processes / services	CIM process classes	Get-Process, Get-Service

One gap worth pinning while the report is fresh: addresses and adapters (Get-NetIPAddress, Get-NetAdapter) are CIM-backed and denied too, but your table does not name a native replacement for them. The IP Helper API path (ipconfig /all) is the obvious candidate, and it is native — but it was not measured in the report, so I would not put it in a documented substitute list until someone confirms it inside the sandbox.

On the silent-value half, I would state it as a rule rather than an aside, because it is the half that produces confident wrong actions: inside the sandbox, a CIM-backed command's empty or zero result is not evidence. Get-PSDrive's Used/Free are WMI-derived and fall back to 0 without an error, and -ErrorAction SilentlyContinue (or 2>$null) erases the denial outright. The invariant worth carrying is that any Windows diagnostic whose answer came from CIM must be corroborated by a native source before it drives a decision.

Disclosure. I am preparing exactly that corroboration as a diagnosis advisory in the Windows-sandbox advisor plugin (@argszero/sandbox-grant-advisor, which already carries five sibling families of this same restricted-token boundary). It would fire on the settled command result — Windows host, a confining mode, this code on the command's stderr — and put the substitute list in front of the model at the moment it would otherwise trust the empty result. I will link the package here once it is published.

[dm11c47333]

Thanks for the careful review — it changed two things in the report rather than just confirming it.

One thing up front: I'm not a programmer, so the technical parts of my replies are prepared with an AI assistant (DeepSeek) and relayed by me. If anything below is imprecise, that's on me.

On the failure surface. You're right, and I've corrected the report. The renderer contract you quoted is verbatim in the shipped app.asar, and my earlier phrasing ("no observable failure signal") was wrong: a CIM access-denied is a non-terminating cmdlet error, so it arrives inside a successful result — on the settled value's stderr, not on the error channel a caller branches on.

On which layer denies. Still open, but narrower now. ManagementScope.Connect() to root\cimv2 succeeds, while every later operation is denied — including a pure repository read (__Namespace) and class enumeration (-List) — and file / registry / netstat / Get-Process / Get-Service are all fine. A denied query also adds zero entries to Microsoft-Windows-WMI-Activity/Operational (that log is readable from inside the sandbox, and it does record operation outcomes for other clients), which reads like a rejection at the service/activation boundary rather than a namespace ACL. That is inference from absence, so I'm not treating it as settled — but it points the same way as your concern, so I've raised the cost estimate for the read-only root\cimv2 option instead of keeping it as "cheapest".

One extra datum for that question: whoami /groups works here and shows BUILTIN\Administrators … Group used for deny only, but it omits the Mandatory Label\… line entirely — consistent with your README's note that token information is only partially available, and the reason I can't confirm the low-integrity half either way.

The gap you flagged is filled — measured, not assumed: ipconfig /all, netsh interface ipv4 show addresses, route print -4 and arp -a all work inside the sandbox, and the substitute table now carries the address/adapter row.

For your advisor, three things that may save a rewrite:

read the settled result's stderr — nothing arrives on isError;
add the address/adapter rows (they're what people reach for first);
don't use ManagementScope.Connect() success as a health signal — it succeeds while every query fails.
And if it isn't too much trouble, please keep suggestions high-level: I can't follow the source-level parts myself. Or simply tell me what you'd like tested, and I'll run it in the sandbox and paste the raw output.

[argszero]

A plugin now ships this boundary as a diagnosis, so a session hits the explanation at the moment the refusal happens.

@argszero/cordis-plugin-sandbox-grant-advisor@0.17.0 — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor (source: https://github.com/argszero/cordis-plugin-sandbox-grant-advisor). Mount the shipped bundle patch in a profile and, inside a confining Windows mode, any command whose own settled stderr carries 0x80041003 beside a CIM context marker gets one durable advisory attached to that exact tool result — once per agent, not once per query.

What it hands over:

• the code and what it means (WBEM_E_ACCESS_DENIED), and that the command and its query are not at fault;
• the harness's own sentence as the mechanism, quoted rather than claimed — packages/sandbox/sandbox-windows-acl/README.md: "Authenticated Users is absent from both lists — the WMI namespace security check fails (0x80041003), so CIM cmdlets and Get-ComputerInfo are unavailable in every confined mode";
• the two silent shapes written as rules, because neither raises anything and an agent will act on the wrong value: -ErrorAction SilentlyContinue turning a refusal into an empty result ("nothing is listening" when the query never ran), and Get-PSDrive reporting 0 for every drive's Used/Free with no error at all;
• the native substitutes measured in this report — netstat -ano, Get-Process, Get-Service, [System.IO.DriveInfo]::new('C').AvailableFreeSpace, Get-Counter '\Memory\Available MBytes', the HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion key — and, stated rather than filled, the two that have none (Get-NetIPAddress, Get-NetAdapter; ipconfig /all is a candidate nobody measured under a confining mode);
• no repair command, with the reason: no ACE closes a namespace check, no elevation reaches it, and the narrow root/cimv2 allowance is a change to the restricted token's own lists — the same absence of Authenticated Users that upstream lists as what closes the C:\-root tree-creation escape.

Two things it is careful about. The mechanism is documented upstream, and the advisory says so and quotes it — what the plugin adds is the just-in-time attribution plus the substitutes and the silent-shape rules the documentation does not carry, not a discovery. And it is recognition-only: it grants nothing, elevates nothing and changes no mode.

On the two requests in the report: (1) is partly answered here for the agent consumer, while the user-facing README wording stays a maintainer-owned change; (2) read-only root/cimv2 remains unpriced, because nobody has measured which of the token's checks refuses the namespace — the advisory says that instead of guessing.

[dm11c47333]

Thanks — and I verified the sentence you quoted before acting on it: it is verbatim in the shipped app.asar (44.0.0), including the clause that ties the limitation to a security property ("…unavailable in every confined mode, and the C:-root tree-creation escape is closed"). That reframes request (2) in my report: the namespace check and a closed escape are the same mechanism, so asking for a read-only allowance is asking to reopen the thing that was closed on purpose. I've updated the report to say that instead of "cheapest".

Two measurements of mine that may bear on the still-unpriced question, since you noted nobody has measured which check refuses the namespace:

• ManagementScope.Connect() to root\cimv2 succeeds, while every later operation is denied — including a pure repository read (__Namespace) and class enumeration (-List). If the namespace security check is the mechanism, that successful Connect() is presumably a client-side/lazy artifact rather than the check passing.
• A denied query adds zero entries to Microsoft-Windows-WMI-Activity/Operational (readable from inside the sandbox, and it does record operation outcomes for unrelated clients) — consistent with a refusal at the namespace check rather than inside an operation.

One question, because it decides whether the advisory reaches the second shape you list: your description triggers on a settled stderr that carries 0x80041003. The Get-PSDrive shape carries no error at all — measured here: all four drives report Used/Free 0 with nothing on stderr. If the matcher needs that marker, that shape never triggers it; and since the advisory is once-per-agent, an agent whose first CIM contact is a silent one gets no advisory at all. Does signature.js cover that path (command/output signatures rather than the error code), or is that a real gap?

On mounting it: I'm going to pass, and I'd rather be straight about why than leave it vague. One reason is risk — it installs into the harness host on a machine that holds an API key. The second is personal — I'm not a developer, and I keep this harness deliberately minimal, so everything mounted is something I have to be able to read and reason about myself; fewer components means fewer things that can surprise me. That's a constraint on my side, not a comment on your plugin, which does one job and states its limits clearly. What I've taken from it instead is the substance: the substitute table and the two silent-shape rules are now a standing line in my workspace's own instruction file, so every session here reads them without any third-party code.

If it's useful, I can still act as a Windows tester without mounting anything: tell me a probe or a signature you want checked for the silent shape and I'll run it in the sandbox and paste the raw output.