fix(windows): accept AppContainer capability grants on runtime ancestors - #1447
fix(windows): accept AppContainer capability grants on runtime ancestors#1447mlandolfi90 wants to merge 2 commits into
Conversation
Sandboxing tools stamp the user profile's AppData with capability ACEs (S-1-15-3-…) holding write rights. The ancestor DACL walk classified them as untrusted grants, so cbm_daemon_ipc_endpoint_new returned NULL and every process on such a machine died at startup with 'secure daemon endpoint could not be created'. A capability ACE grants only to AppContainer processes provisioned by the same user's tooling, and the runtime directory itself still demands the exact-user owner plus a protected DACL. Accept capability SIDs on ancestor components only; the final directory validation is unchanged. Observed in the field: AppData carrying two capability ACEs with mask 0x000d0152 (FILE_DELETE_CHILD, DELETE, WRITE_DAC among them) stamped by an agent-sandbox provisioner. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: mlandolfi90 <mlandolfi90@users.noreply.github.com>
|
Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. Current review status: working through a backlog. What that means for this PR, concretely:
Things that will genuinely speed it up whenever review does happen:
If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. Thanks for contributing, and sorry in advance for the wait. |
The bundle contract pins the ancestor validation call by literal text, so adding the capability parameter turns it red on every platform (the check reads source, it does not compile). Update the needle, and use the opportunity to pin what actually matters about this change: the ancestor call passes true, the final runtime directory still passes false, and the capability test exists. A future edit that let a capability ACE satisfy the published runtime directory now fails this contract. Signed-off-by: mlandolfi90 <mlandolfi90@users.noreply.github.com>
|
CI update — the platform-wide red was real and mine, and it is worth naming precisely because it is a good guard.
"win_file_security_secure(security, directory, false, mutation)",Adding the capability parameter changed that text, so the contract failed on Linux and macOS too — the check reads the source rather than compiling it. That is the guard doing its job: it is exactly the line that decides how much an ancestor is allowed to grant, and it should not move quietly. I have pushed an update to the needle, and used the occasion to pin the property this PR actually needs to be true rather than just the call shape: "win_file_security_secure(security, directory, false, mutation, true)",
"win_private_mutation_rights(), false)",
"win_sid_is_app_capability",The middle one is the important addition: it pins that If you would rather this guard not be touched by a contributor PR at all, say so and I will drop the test commit and let you land the needle change yourself. The remaining 🤖 Generated with Claude Code |
…me dir strict Six independent machines in DeusData#1533 and DeusData#1574 cannot run cbm at all, and none of them is exotic: a domain-joined UAC-filtered admin, a secondary volume, orphaned ACEs from an uninstalled application, and an AppContainer package SID belonging to a shipping desktop application. The ancestor walk was identity-blind to all of it. win_directory_component_secure demanded that no ancestor DACL entry grant any private-mutation bit to any SID outside the trusted set, so a single ACE anywhere up %LOCALAPPDATA% refused the endpoint before logging started. Every mode failed, config list included, so the product could not even be reconfigured out of it, and CBM_CACHE_DIR does not help because the runtime directory is %LOCALAPPDATA%\cbm-daemon-<hash>, whose ancestor chain relocating the cache never touches. Ancestor components now also tolerate AppContainer identities: package SIDs (S-1-15-2-*) and capability SIDs (S-1-15-3-*), under identifier authority 15. The boundary is ancestor-only. The private runtime directory is validated with ancestor=false and keeps demanding the exact current user with a protected DACL; the flag is threaded explicitly through win_file_security_secure and win_file_acl_secure rather than inferred, so the strict path cannot acquire the tolerance by accident. Why these identities are admissible on an ancestor: a process cannot choose which AppContainer it runs in. The identity is stamped by the OS at process creation from the package it was launched from, so such an ACE cannot be exercised by arbitrary local code the way a live local group can. What it does permit is the packaged application itself — that is the residual risk this accepts, and it is the same trust already extended to whoever installed that package. BOTH forms are covered deliberately. The most common real ACE of this shape is S-1-15-2-*, a package SID; on reported machines it resolves through the registry AppContainer mappings to Anthropic Claude Desktop, which many of our users run and cannot be asked to uninstall. Covering only capability SIDs leaves exactly that case failing. This narrows a deliberate policy: the strict gate was chosen on purpose and a middle ground was previously declined. It is reopened here by explicit maintainer decision, and narrowed as far as the evidence allows rather than relaxed wholesale — a live local group, Authenticated Users on a secondary volume, and orphaned unresolvable SIDs all still refuse. Those need CBM_RUNTIME_DIR or a separate change; orphan tolerance in particular needs LookupAccountSid bound first and has an offline-domain-controller caveat, so it is not bundled in here. Approach and the ancestor-only boundary follow @mlandolfi90's PR DeusData#1447, extended from capability SIDs to package SIDs. Co-Authored-By: mlandolfi90 <mlandolfi90@users.noreply.github.com> Contract-pinned in tests/test_windows_bundle_contract.sh and revert-checked in both directions: reducing it to capability-only fails, and passing ancestor=true for the runtime directory fails. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
|
Thank you for this — and I owe you an apology, because the way this played out is not how it should have gone. Your approach shipped. It is on
The one thing we changed is the SID class. You tested Your ancestor-only boundary is the part that made it safe to do at all, and it is preserved exactly: the private runtime directory is still validated with It ships in v0.10.5, going out today. What I'm sorry about: you opened four PRs on 2026-08-04 (#1444, #1445, #1446, #1447), three of which turned out to be fixed independently, and nobody told you — including on this one, where your work went into the product. That is a bad experience for someone who showed up with a correct diagnosis and a working patch, and the silence was ours, not a judgement on the work. I'm going through the other three now. |
2 participants
Symptom
On an ordinary Windows 11 developer machine, every CBM process died at startup:
No CBM process was competing, and the same machine had run a daemon for days on an older build. The cause is environmental and, I suspect, increasingly common: an agent sandbox (Codex) had stamped the user's
AppDatawith capability ACEs.win_private_directory_tree_securewalks every ancestor of the runtime directory and refuses any mutation-granting ACE whose SID is not the exact user, SYSTEM, Administrators, TrustedInstaller, CreatorOwner (inherit-only) or OWNER RIGHTS. A capability SID matches none of them, socbm_daemon_ipc_endpoint_newreturns NULL and the process exits — including plain--version-adjacent paths that construct an endpoint.Why I think accepting them on ancestors is sound
A capability SID (
S-1-15-3-…,SECURITY_APP_PACKAGE_AUTHORITY) grants only to AppContainer processes that the same user's tooling provisioned. It cannot be used by another account, and it does not confer rights on a normal process. This is the same shape of argument the OWNER RIGHTS acceptance in 8b4e0fb already makes: the grant is reachable only by the party the walk is protecting.The relaxation is deliberately narrow:
win_directory_component_securepassesancestor_capability_ok = true.win_runtime_directory_securepassesfalse, so it still demands the exact-user owner and a protected DACL, and still re-stamps it.15) and the capability RID class (3) explicitly, so it cannot widen to otherS-1-15-*classes.Note on the trust model
This does move a trust boundary, so I understand if you would rather discuss it in an issue before reviewing code — happy to convert. I am also open to a narrower shape if you prefer one: gating it behind an opt-in, or restricting acceptance to ancestors that lie inside the user's own profile.
What I would push back on is leaving it as-is: the failure gives the user one sentence with no cause, and the only remedies available to them are removing ACEs their sandbox depends on, or not running CBM.
🤖 Generated with Claude Code