coulomb/whitehat-security
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record E2 target applicability constraints

Browse source 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0260c-4067-7052-9647-ad000d576e38
This commit is contained in:
tegwick 2026-08-22 00:08:23 +02:00
parent cf696f09d5
commit db6b14f764
2 changed files with 56 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

47
docs/target-applicability.md Normal file
View file

@ -0,0 +1,47 @@
# Target applicability for WHITEHAT-WP-0001
Status: active review, 2026-08-22
The E2 attacker model requires an authenticated identity that is legitimately
authorized for tenant A and not tenant B. A target name alone is insufficient;
the target must expose a boundary where that identity exists.
## audit-core — applicable
`audit-core` binds each sender token to allowed sources, tenant set, read and
write capabilities at one application choke point. Two distinct ordinary
sender identities scoped one per fixture tenant instantiate the model without
operator or database privilege. Its event-id, correlation and append routes
therefore form a valid E2 differential.
The target owner reviewed the route and identity design on 2026-08-21. Formal
acknowledgement and value-safe provisioning remain required by
`WH-ENG-20260821-AUDIT-E2`; no target traffic is permitted while its
`target_owner_acknowledged_at` is empty.
## tenant-engine — E2 applicability not established
The original workplan named `tenant-engine` because its declaration said an E2
mechanism was implemented. Cold review of the actual contract shows that this
does not supply the attacker identity T03 assumes:
- `tenancy.yaml` declares current E1/A0, not E2, and says inbound actor/tenant
values are not verified.
- The flex-auth policy registers the platform-wide `tenant-engine` service
subject for administrative actions. It is not a tenant-A subject and is
deliberately allowed to address tenant B.
- Tenant registry enumeration is the service's function and is an explicit
placement exception. Cross-tenant access by its authorized platform operator
is not a tenant-boundary failure.
- Substituting an unregistered actor would test caller authorization (A), not
E2. Substituting the all-tenant service actor would give the modeled attacker
authority it is supposed not to hold.
Therefore no production packet is sent under
`WH-ENG-20260821-TENANT-E2` until the target owner names a real authenticated
tenant-A identity with no tenant-B authority. If none exists, the honest
artifact is `not applicable`, and the workplan acceptance must stop naming
tenant-engine as though it claimed an exercisable E2 boundary. Its existing
A/I gaps remain target-owned; whitehat must not relabel them to make this plan
finish.

9
workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md
View file

@ -151,6 +151,15 @@ route inventories live in `probe-packs/tenant-engine-e2.json` and
`probe-packs/audit-core-e2.json`. The two target runs remain gated on complete
engagement records, owner acknowledgements and executable identity adapters.
Production engagements were operator-approved on 2026-08-21 and committed in
`engagements/`. Audit-core accepted the route/identity shape and reviewed the
adapter; its first review caught a missing idempotency header before traffic,
which is corrected and regression-tested. `docs/target-applicability.md`
records a separate issue: tenant-engine currently exposes no authenticated
tenant-A identity with no tenant-B authority, so its E2 applicability is
pending owner confirmation rather than being faked with its all-tenant service
operator or an unauthenticated actor.
### T04 — Prove the probes fail
```task