tegwick
0bc624ba62
secrets-engine's first live request rejected our allow: binding. request_digest is computed over material they never sent, because we enrich subject and resource from the registry before hashing. Answering that meant reading the enrichment path, which had a worse defect in it. Enrichment was additive-if-absent — addAttribute wrote a registry value only where the request had no value for that key. So where a caller supplied a key, the caller's value won and the registry's never applied. Every registry ceiling and allowlist was advisory. Verified against the shipped ops-warden package, each one added key on an otherwise-denied request: max_ttl_hours: 99 registry says 8 -> allowed a 12h certificate allowed_principals registry allowlist -> disallowed_principal bypassed allowed_subjects registry allowlist -> unknown_subject bypassed The third is the one to read twice: a subject the registry does not know authorized itself by naming itself in the allowlist it was being checked against. Not remotely reachable today — the PEP builds the CheckRequest, ops-warden sends no resource.attributes, and enforce admits one identity. It is a defence-in-depth failure: any path that lets attacker-influenced data into a CheckRequest field became a full policy bypass rather than a bounded input problem. Callers sending resource.attributes is not hypothetical; secrets-engine does it on every request. Registry facts now win, and diagnostics.registry_overrode names every displaced key, because a registry that silently discards a contradicting claim hides that a caller asserted authority it did not have. subject.type is carved out, and the reason is a finding of its own. Making the registry win there denied every secrets-engine allow: the registry's type is CARING vocabulary (Human, Agent, Automation, Service) and the request's is the protected system's actor vocabulary (service, adm, agt, atm). Two fields sharing a name; substituting one for the other is translation rather than identity, which GH-DEC-2026-008 ruled against. Note what surfaced it — the registry's type had been dead data since the field existed, because the caller's value always won. Also publishes binding.submitted_request_digest, over the request exactly as sent. request_digest was published as the consumer replay test and cannot be one. Nothing is lost hashing the pre-enrichment form: enrichment is a function of the request and the snapshot, and registry_snapshot_digest already pins the snapshot. Existing pins do not move. All three replay fixtures' request_digest and approval_binding_digest values are byte-identical — those requests contradict no registry fact. A field to add, not a value to correct. Regression tests verified failing against the old behaviour before being kept. FLEX-DEC-2026-012; FLEX-WP-0025 carries the residual, that a policy still cannot tell a fact from an assertion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd Assistant: claude-code Assistant-Model: opus Assistant-Process: 715613@bnt-lap001 Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80
4.5 KiB
| id | type | title | domain | repo | status | owner | topic_slug | planning_priority | planning_order | depends_on_workplans | related_workplans | created | updated | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FLEX-WP-0025 | workplan | A policy cannot tell a registry fact from a caller assertion | infotech | flex-auth | ready | claude | netkingdom | P1 | 250 |
|
|
2026-09-07 | 2026-09-07 |
FLEX-WP-0025 — A policy cannot tell a registry fact from a caller assertion
Opened by FLEX-DEC-2026-012. That decision closed three verified privilege
escalations by making registry facts win over caller-supplied attributes. It did
not close the shape that produced them.
input.resource.attributes.max_ttl_hours reaches a Rego rule as one value in one
map. Nothing in that input says whether the registry asserted it or the caller
did. Precedence decides which value survives; it does not let a policy author
require that a ceiling came from the registry at all.
The two residuals precedence did not close
1. A key the manifest omits is caller input. Registry facts win only where the registry has a value. A package branching on an attribute its manifest does not declare is reading the caller, and a manifest that stops declaring a key silently hands that key back. Registering the resource is not sufficient — the specific key must be present.
2. subject.type is two fields sharing a name. The registry's type is
CARING vocabulary (Human, Agent, Automation, Service); the request's is
the protected system's actor vocabulary (service, adm, agt, atm).
Policies compare against the latter. Making the registry win here denied every
secrets-engine allow, because "Service" is not "service", so the exception
stands — and a caller can still assert its own subject.type while packages
branch on it.
Note how the second surfaced: the registry's type had been dead data since the
field existed, because the caller's value always won. A defect is invisible
while the value it produces is never read.
1. Decide the shape
id: FLEX-WP-0025-T01
status: todo
priority: high
Owner: flex-auth.
The obvious move is separate namespaces — input.resource.registry.* for facts
and input.resource.asserted.* for caller input, with attributes retained as
the merged view. That breaks no package on day one and lets a rule that enforces
a ceiling opt into the fact side.
Weigh against it: a third view invites a package to read the merged one by habit, which is the status quo with extra steps. A stricter alternative is to stop merging at all and require packages to name a side, accepting a breaking change across six published packages.
Do not decide this from the shape alone. Read what the six packages actually
branch on first, and write down which of their reads are ceilings or allowlists
(must be facts), which are genuinely caller-proposed (ttl_hours, purpose),
and which are ambiguous. The ambiguous set is the real design input.
Gate: the chosen shape is written down with the vocabulary collision addressed, before any package changes.
2. Audit every package for ceilings read from undeclared keys
id: FLEX-WP-0025-T02
status: todo
priority: high
Owner: flex-auth.
Mechanical and worth doing before T01 lands, because it is the live residual.
For each published package, list every input.*.attributes.<key> read, and check
the key is declared in the manifest for every resource that package can be asked
about.
Any ceiling or allowlist read from a key the manifest does not declare is a live
escalation of the FLEX-DEC-2026-012 shape. Fix by declaring the key, not by
changing the rule.
Gate: a table of package × key × declared-in-manifest, with no ceiling or
allowlist unbacked. Add it to docs/request-enrichment.md.
3. Make the review obligation enforceable rather than written
id: FLEX-WP-0025-T03
status: wait
priority: medium
Owner: flex-auth.
docs/request-enrichment.md now says a policy enforcing a ceiling MUST read a
key its manifest declares. A review obligation nothing checks is the shape
FLEX-DEC-2026-008 was about.
Extend flex-auth validate to report attribute keys a package reads that its
fixtures' registry never supplies. It cannot prove intent — it does not know
which reads are ceilings — but it can surface every read that resolves only from
caller input, which is the set a reviewer must look at.
Gate: the check runs in validate and flags a package whose ceiling key is
undeclared, demonstrated against a deliberately broken fixture package.