From 25a07d16f7c270677a8a83c5012addd3ee6f4864 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 21 Aug 2026 23:09:22 +0200 Subject: [PATCH] Approve rules of engagement and define attacker models Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a0260c-4067-7052-9647-ad000d576e38 --- AGENTS.md | 7 +- README.md | 3 +- SCOPE.md | 15 +- WORK-RECORDS.md | 6 +- docs/attacker-model.md | 256 ++++++++++++++++++ docs/rules-of-engagement.md | 16 +- .../WHITEHAT-WP-0001-cross-tenant-evidence.md | 21 +- 7 files changed, 298 insertions(+), 26 deletions(-) create mode 100644 docs/attacker-model.md diff --git a/AGENTS.md b/AGENTS.md index b7f2a4a..3274624 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -25,9 +25,10 @@ responsible party. ## Non-negotiable safety boundary -- The rules of engagement are pending personal operator approval. Until they - are approved, perform only documentation work and non-networked fixture - design. Send no packets to a target. +- The rules of engagement are accepted, but that acceptance authorizes no live + target. Without a complete, target-specific engagement record and every + approval required by the rules of engagement §1, perform only documentation + work and non-networked fixture design. Send no packets to a target. - Even after approval, no live run starts without a dated engagement record naming authorization, target owner, exact scope, window, technique, credentials, rate/concurrency ceiling, abort contact and finding destination. diff --git a/README.md b/README.md index b863063..10512f9 100644 --- a/README.md +++ b/README.md @@ -22,5 +22,6 @@ probes most worth having are the ones an author would not think to write. - Intent: [`INTENT.md`](INTENT.md) - Scope: [`SCOPE.md`](SCOPE.md) - Workplans: [`workplans/`](workplans/) -- Rules of engagement (pending operator approval): +- Attacker model: [`docs/attacker-model.md`](docs/attacker-model.md) +- Rules of engagement (accepted; live targets still require engagement approval): [`docs/rules-of-engagement.md`](docs/rules-of-engagement.md) diff --git a/SCOPE.md b/SCOPE.md index bc27a5a..7724778 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -35,8 +35,9 @@ boundary always holds. ## Safety invariants -- Until the rules of engagement receive personal operator approval, only - documentation and non-networked fixture design may proceed. +- The rules of engagement are accepted, but their acceptance authorizes no live + target. Without a complete approved engagement record, only documentation + and non-networked fixture design may proceed. - No live target is authorized by this scope document. - Every live run names its authorization, target, owner, window, technique, credential lane, rate ceiling, abort contact and finding destination. @@ -65,10 +66,12 @@ boundary always holds. - Repository status: active. - Active plan: `WHITEHAT-WP-0001`. -- `T01` is in progress: the rules of engagement are drafted and awaiting - personal operator approval. -- No live probe traffic is authorized yet. -- `T02` through `T07` remain gated by `T01`. +- `T01` is complete: the rules of engagement were accepted on 2026-08-21. +- `T02` is complete: the per-axis attacker model is recorded in + `docs/attacker-model.md`. +- `T03` is ready to begin with offline harness and fixture design. +- No live probe traffic is authorized; each target still requires its own + engagement record and approvals. ## Relationships diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 9efa35b..7a823e2 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -9,9 +9,9 @@ | Kind | ID | Status | Lane | Source | | --- | --- | --- | --- | --- | | workplan | WHITEHAT-WP-0001 | active | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | -| task | WHITEHAT-WP-0001-T01 | progress | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | -| task | WHITEHAT-WP-0001-T02 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | -| task | WHITEHAT-WP-0001-T03 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | +| task | WHITEHAT-WP-0001-T01 | done | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | +| task | WHITEHAT-WP-0001-T02 | done | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | +| task | WHITEHAT-WP-0001-T03 | todo | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | | task | WHITEHAT-WP-0001-T04 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | | task | WHITEHAT-WP-0001-T05 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | | task | WHITEHAT-WP-0001-T06 | wait | — | workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md | diff --git a/docs/attacker-model.md b/docs/attacker-model.md new file mode 100644 index 0000000..0f25bbb --- /dev/null +++ b/docs/attacker-model.md @@ -0,0 +1,256 @@ +# Attacker model for tenancy evidence + +Status: **active** + +Version: 0.1 + +Date: 2026-08-21 + +Owner: NetKingdom / `whitehat-security` + +Governing rules: [`rules-of-engagement.md`](rules-of-engagement.md) + +## 1. Purpose + +This document states what an adversary is assumed to hold for each probe +family. It prevents two opposite errors: + +- testing a weaker attacker than the posture claim requires and reporting a + misleading pass; +- giving the attacker powers outside the claimed control and reporting a + documented limitation as a failed control. + +The model is part of every run record. A run without a named model is +inconclusive. + +## 2. Common conditions + +Every model below inherits these conditions: + +- The target, time window, technique, source, rate ceiling and abort contact + come from an approved engagement record. +- Tenant A and tenant B are disposable fixtures created for the engagement. + Real tenant data is never used as bait or retained as evidence. +- Knowing tenant B's fixture identifiers is an orchestration capability, not + evidence that the target disclosed them. Identifier discovery is tested + separately when it is in scope. +- The adversary may repeat, reorder and vary operations that an ordinary holder + of its stated capability can perform. It does not gain unlisted privilege + merely because the harness could obtain it. +- Evidence stores status, counts, schema shape and run-local digests—not + response bodies, credentials or real tenant values. +- Outcomes are `pass`, `finding`, `inconclusive` or `aborted`. This repository + assigns no severity. +- A pass means only that the attacks attempted under this model did not work. + +## 3. E2 — authenticated tenant A at the service boundary + +### Adversary holds + +- A legitimate runtime or user credential accepted by the target. +- Valid authority for tenant A and no authority for tenant B. +- The ability to make ordinary supported requests. +- Tenant B fixture object identifiers supplied by the harness. + +### May attempt + +- Substitute tenant B identifiers into paths, query parameters, bodies, + cursors, filters, batch items and relationship traversals. +- Replay a valid tenant A request while changing one tenant-bearing field at a + time. +- Exercise read, create, update and delete surfaces covered by the engagement. +- Compare tenant A and tenant B responses, including status, count, schema + shape, timing class and subsequent fixture state. + +### Does not hold + +- SQL execution, a database credential, service-process control, operator + authority or tenant B membership. +- Permission to enumerate unrelated production identifiers or retain returned + tenant data. + +### Finding condition + +The tenant A identity reads tenant B fixture content, changes tenant B fixture +state, creates data attributed to tenant B, or obtains a cross-tenant +relationship it is not permitted to observe. A well-formed `200` is not a pass; +the response and resulting state must be compared with the fixture oracle. + +`403`, `404` and empty results can each be valid target behavior. The evidence +records behavior without requiring one status code, while checking that the +surface does not become an existence oracle when that is part of the target's +claim. + +### What a pass supports + +Only the E2 claim for the exercised choke point, operations, target revision and +review date. It says nothing about an unexercised route, SQL injection or +process compromise. + +## 4. E3 — platform-assisted filtering + +E3 layers on E2 and has two deliberately different models. + +### E3-A: omitted-predicate or bypassed-choke-point accident + +The adversary is a defective code path, not a compromised process. + +It holds the ordinary leased database role and runs inside an explicit +transaction with tenant A set using the documented transaction-local GUC. It +may issue a query that omits the service-side tenant predicate or bypasses the +E2 choke point. + +A tenant B row becoming visible or writable is a finding. E3 exists to stop +this case. + +The conformance run also checks: + +- every tenant-owned table enables and forces RLS; +- every policy covers reads and writes; +- the runtime and leased roles lack `BYPASSRLS`; +- an unset GUC reads no rows; +- tenant A's GUC reads or writes no tenant B rows; +- ordinary callable functions do not acquire a table owner's exemption through + an unreviewed `SECURITY DEFINER` path; +- hot-query plans have a recorded before/after comparison. + +A missing policy, `BYPASSRLS` grant or unsafe definer function is a +configuration finding. The harness must not grant those powers merely to make +the attack stronger. + +### E3-B: SQL-capable compromise + +The adversary holds SQL execution on the ordinary runtime connection. It may +issue another `SET LOCAL` and change the custom tenant GUC to tenant B. + +Cross-tenant access after that reset is **the documented limit of E3**, not an +E3 conformance failure. The run records the observation so reports cannot +silently imply that E3 withstands SQL injection or process compromise. + +If the same credential cannot address tenant B even after the reset, that may +be evidence of E4-shaped structural confinement, but it does not upgrade the +claim without the E4 model and substrate evidence. + +### What a pass supports + +E3-A supports protection against omitted predicates and bypassed application +paths for the exercised schema revision. E3-B has no expected E3 pass: +its purpose is to demonstrate and preserve the boundary of the claim. + +## 5. E4 — leaked per-tenant credential + +### Adversary holds + +- Tenant A's real per-tenant credential, leased for the engagement. +- The connection information that an ordinary tenant A workload receives. +- Knowledge of the separately provisioned tenant B fixture substrate. + +### May attempt + +- Present tenant A's credential to tenant B's endpoint or database. +- Address tenant B through alternate database names, schemas, hosts or routing + fields exposed to the ordinary workload. +- Reuse the credential until its recorded expiry, without extending or + refreshing it outside its normal authority. + +### Finding condition + +Tenant A's credential authenticates to, addresses, reads from or writes to +tenant B's substrate. Network reachability alone is recorded but is not an E4 +failure unless the claim includes network isolation; E4's core assertion is +credential and substrate confinement. + +### Does not hold + +A platform, migration, break-glass or tenant B credential; control of the +credential issuer; or permission to alter routing/provisioning state. + +## 6. Shared P1/P2 capacity — bounded co-resident + +This model tests capacity assurance, not the truth of the P1/P2 topology. + +### Adversary holds + +- A legitimate co-resident consumer identity. +- Its declared connection, query, CPU, memory or request allowance. +- The ability to generate synthetic load up to the engagement's explicit + ceiling. + +### May attempt + +- Saturate its own declared allowance during the approved window. +- Use the permitted mix of expensive and concurrent operations. +- Continue until a governor binds, an abort threshold fires or the window ends. + +### Finding and measurement conditions + +- A claimed governor does not bind at its declared ceiling. +- Co-resident degradation is not measured against each consumer's declared + service class. +- Aggregate headroom and shared failure conditions are omitted from the record. + +If the harness exceeds the aggressor's authorized allowance, the run aborts and +is treated as a probe-control incident—not as a target finding. + +Zero co-resident degradation is not expected on shared infrastructure. The +artifact records what degradation occurred and whether the responsible owner +accepts it; the probe does not manufacture a guarantee that P1/P2 cannot +provide. + +No capacity probe has a default live authorization. Its engagement requires a +separate operator-approved window and explicit abort thresholds. + +## 7. R4 — pre-erasure retained copy + +The adversary holds an authorized copy created before erasure and the metadata +that legitimately survives under the target's declared R4 route. It attempts +recovery only against synthetic fixture data. + +### R4-A: horizon-elapsed + +After the published erasure horizon, attempt to recover the fixture from live +storage, backups, replicas, exports, indexes and declared derived copies. +Recoverable content after the horizon is a finding. + +### R4-B: key-destroyed + +After recorded destruction of the fixture's per-entity key, attempt to decrypt +every retained ciphertext and use retained hashes, chains, indexes or search +keys as confirmation oracles. + +Readable content, a surviving usable key, or a retained low-entropy commitment +that confirms guesses about erased content is a finding. Destruction of a key +alone is not a pass. + +### Does not hold + +An undeclared backup, escrow or recovery key invented for the test. If the +evidence inventory cannot show that every declared copy was exercised, the +outcome is inconclusive rather than pass. + +`audit-core` is not an R4 target under its current integrity-chain design; it +targets R2. The facility does not erase the evidence service's retained facts +to satisfy a fleet-wide aspiration. + +## 8. Axes outside this first model + +Identity (`I`), authorization (`A`) and availability (`V`) have evidence +requirements in Tenancy Posture, but `WHITEHAT-WP-0001` does not yet define +their adversarial facilities. A run under this document must not claim evidence +for those axes merely because it observed related behavior. + +## 9. Model selection and review + +Each engagement record names: + +- the model and subsection used; +- the target revision and posture claim; +- the exact credential or identity class, never its value; +- all deliberate deviations from the common conditions; +- the known-bad fixture that proves the probe can fail; +- the review date and scheduled rerun date. + +Review this model when the canonical posture mechanism changes, a target gains +a new credential or cross-tenant path, a probe discovers an unmodeled +capability, or a pass depends on excluding behavior an ordinary attacker could +perform. diff --git a/docs/rules-of-engagement.md b/docs/rules-of-engagement.md index 3747aca..407dfd3 100644 --- a/docs/rules-of-engagement.md +++ b/docs/rules-of-engagement.md @@ -1,6 +1,6 @@ # Rules of engagement for tenancy evidence -Status: **pending personal operator approval** +Status: **accepted** Version: 0.1 @@ -139,7 +139,13 @@ known-good fixture in the same revision. ## 10. Approval -Personal operator approval is still required. Record approver, date and scope -in this section or an immutable linked decision before changing the status to -accepted. Until then, only documentation and non-networked test-fixture design -may proceed; no target packets are authorized by this draft. +Approved by: **repository operator**, by explicit approval in the coordinating +session + +Approval date: **2026-08-21** + +Approved scope: these rules are accepted as the operating boundary for +`whitehat-security`. This approval permits documentation and non-networked +fixture work. It does **not** authorize a live target or a packet to any target. +Every live run still requires the engagement record, target-owner +acknowledgement and any technique-specific operator approval required by §1. diff --git a/workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md b/workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md index 3fbfdbd..838b4c2 100644 --- a/workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md +++ b/workplans/WHITEHAT-WP-0001-cross-tenant-evidence.md @@ -80,7 +80,7 @@ As above. Gates everything. ```task id: WHITEHAT-WP-0001-T01 -status: progress +status: done priority: high state_hub_task_id: "0d28fd14-1b82-4ac1-907b-02f43e8baae8" ``` @@ -88,14 +88,15 @@ state_hub_task_id: "0d28fd14-1b82-4ac1-907b-02f43e8baae8" Drafted in `docs/rules-of-engagement.md` on 2026-08-18 with authorization classes, per-run records, initial target envelope, hard prohibitions, credential/attribution rules, rate defaults, abort/cleanup and evidence -schema. It authorizes no live traffic until the operator personally approves -§10. T01 remains progress and continues to gate every later task. +schema. The operator accepted v0.1 on 2026-08-21 with the scope recorded in +§10. The acceptance approves the operating rules and offline fixture work; it +does not pre-authorize any live target. ### T02 — The attacker model per axis ```task id: WHITEHAT-WP-0001-T02 -status: wait +status: done priority: high state_hub_task_id: "e0070ee6-6060-4a29-bd88-f664034db28e" ``` @@ -112,15 +113,19 @@ distinguishes them: | P1/P2 | A co-resident consumer behaving badly within its own allowance | What degradation do neighbours experience? | | R | A copy of a backup taken before an erasure | Is the erased data still readable? | -**Output:** `docs/attacker-model.md`. Note that the E3 row exists because the -framework corrected itself: E3 stops accident, not compromise, and a probe that -only tested accident would report a strength E3 does not have. +**Output:** `docs/attacker-model.md`, completed 2026-08-21. It separates +credential-bearing tenant attacks, omitted-predicate accidents, SQL-capable +compromise, structural credential confinement, bounded co-resident saturation, +and both R4 erasure routes. It preserves the framework's correction that E3 +stops accident, not compromise: resetting the tenant GUC after SQL execution +is recorded as E3's documented limit, not misreported as an E3 conformance +failure. ### T03 — Differential cross-tenant harness (the E2 artifact) ```task id: WHITEHAT-WP-0001-T03 -status: wait +status: todo priority: high state_hub_task_id: "742561f1-97b6-4fcc-8e06-d18508ddecae" ```