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
122 lines
4.5 KiB
Markdown
122 lines
4.5 KiB
Markdown
---
|
||
id: FLEX-WP-0025
|
||
type: workplan
|
||
title: "A policy cannot tell a registry fact from a caller assertion"
|
||
domain: infotech
|
||
repo: flex-auth
|
||
status: ready
|
||
owner: claude
|
||
topic_slug: netkingdom
|
||
planning_priority: P1
|
||
planning_order: 250
|
||
depends_on_workplans:
|
||
- FLEX-WP-0021
|
||
related_workplans:
|
||
- FLEX-WP-0022
|
||
- FLEX-WP-0024
|
||
created: "2026-09-07"
|
||
updated: "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
|
||
|
||
```task
|
||
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
|
||
|
||
```task
|
||
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
|
||
|
||
```task
|
||
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.
|