open-standards/sandbox/conformance
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 96cd5e98a0
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 5s
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 48s
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m41s
standards workspaces build + test / joule-ui-rs (joule-ui/joule-ui-rs, joule-ui-rs, linux) (pull_request) Successful in 1m10s
standards workspaces build + test / proof-rs (proof-conformance, proof/proof-rs, proof-rs, linux, true) (pull_request) Successful in 2m18s
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, sandbox-rs, linux) (pull_request) Successful in 2m38s
standards workspaces build + test / joulecontract-rs (joulecontract/joulecontract-rs, joulecontract-rs, linux-arm64, true) (pull_request) Successful in 2m43s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 5m23s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 13m57s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 4m28s
sandbox: flow across a run's checkpoints — an untrusted read closes the sinks that follow
Sweep 2026-10-19 item #7, second half, by the owner's decision. Each
checkpoint was decided alone: a unit could read data an attacker writes and
later reach an endpoint it is granted, each call passing its own check, and
nothing connected the read to the egress. The Enforcer is stateless by
design (C2), so the connection had to be state the run carries explicitly.

sandbox-capability (SPEC §5.8):
- Grants.flow: FlowGrant { untrusted: [FlowSource { kind: Path|Kv|Program,
  pattern, origin }], tainted_may: [FlowSink { kind: Egress|Exec, target,
  accepts }] }. Omitted when empty, so a grant set without it keeps its bytes.
- RunTaint: the origins of untrusted data a run has read; only grows.
- Two pure Enforcer functions: taints(source), the origins a read adds; and
  may_reach(sink, &taint), where a tainted run reaches a sink only where
  tainted_may opens it to EVERY origin it carries (entries combine; `*`
  opens to any target or origin; an unopened sink is closed). Additional to
  the sink's capability, never instead. A decision stays a function of its
  inputs, the run's taint among them, as I/O counters already are.

sandbox-exec-wasm (S2, where the live checkpoints are): HostState carries
the taint. A storage or kv read that returns data, and a program's output,
taint the run from a source the grant marks; egress and exec are refused
with TAINTED (-6, distinct from DENIED) when the grant has not opened them
to the run's origins. sandbox-exec-os is untouched: it refuses network and
process grants outright, so no sink is reachable there.

sandbox-runtime: grants_content_id binds flow_untrusted and
flow_tainted_may when present, so the flow grant is part of the capability
surface (SPEC §1.2); a grant without one keeps its id.

Conformance class C13: sequence vectors (a run's calls in order; reads
check the origins after, sinks whether reachable), in code and in the new
conformance/v1/flow.json. The pack count goes to 13.

SPEC §5.8, spec/capabilities.md (the enforcer contract: pure, with the
run's history as an input), spec/conformance.md, conformance/v1/README.md;
SPEC §10's class list was missing C11 and C12 and now lists C11–C13.

Residuals, stated in §5.8: an unmarked source is read as the principal's
data, and a tainted run's writes are not marked, so data can lose its taint
between runs.

Note: running gen_vectors also rewrites attestation.json and negative.json
with "mechanism": null, a drift that predates this change; left out of it.

Tests:
- capability: three unit tests (a read carries every matching source's
  origin, kinds do not cross, `*` is any program; a tainted run reaches
  only what is opened to all it carries, entries combine; the taint only
  grows and an empty flow grant is not encoded).
- exec-wasm: three end-to-end through real guests (an untrusted storage,
  kv or program read closes the egress that follows, a clean read leaves it
  open; an untrusted read closes the launch that follows; a sink opens only
  to the origins named, and no flow grant is untouched).
- runtime: the flow grant is bound into the grant id, every part of it.
- C13.
Mutation testing: 17 mutants; 16 killed, 1 equivalent (the clean-run early
return in may_reach: an empty taint already satisfies "every origin").

Verified on the build host: sandbox-rs 428 tests (--locked); every
conformance class passes, C13 in code and from flow.json; clippy -D
warnings clean on sandbox-capability, -exec-wasm, -runtime, -conformance.
Repo checks pass.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-21 10:49:52 -04:00
..
v1 sandbox: flow across a run's checkpoints — an untrusted read closes the sinks that follow 2026-10-21 10:49:52 -04:00
README.md Add aac, map, sandbox standards; catalog the standards family 2026-06-07 17:04:36 -04:00
VERSIONS.md Add aac, map, sandbox standards; catalog the standards family 2026-06-07 17:04:36 -04:00

Sandbox conformance vectors

Signed, content-addressed wire vectors for the Sandbox standard (SPEC §10, ../spec/conformance.md). An implementation is conformant for the tiers it advertises if it round-trips these vectors with no skips.

The vectors are the authority. They are not illustrative: each is a real, cryptographically computed value, and the reference harness recomputes every content address, sealed JCR-1 envelope, and Ed25519/JCS signature and checks it against the committed file. A change to wire behaviour MUST regenerate the vectors and note it in VERSIONS.md.

Layout

conformance/
├── README.md        — this file
├── VERSIONS.md      — vector-set changelog
└── v1/              — the v1 vector set
    ├── content_addressing.json   — C1: bytes → BLAKE3 content id
    ├── capability.json           — C2: grant set → allow/deny decisions (incl. negatives)
    ├── receipt.json              — C3: per-device receipt → core, content id, sealed JCR-1 envelope
    ├── attestation.json          — C4: attestation → JCS bytes, content id, Ed25519 signature
    ├── tier.json                 — C5: grant set + flags → required tier
    ├── negative.json             — C-neg: malformed receipts + attestations a host MUST reject
    └── confidential.json         — C-tee: SEV-SNP report verification + audit-chain vectors

Vector classes

  • C1 — canonicality. Content addressing (b3: + base64url over BLAKE3-256) is byte-stable.

  • C2 — capability enforcement. The deny-by-default Enforcer returns the fixed decision for each query, including the negatives (ungranted device class, read-only path written, wrong port).

  • C3 — receipt integrity. The per-device records sum to the total; the (provenance, measured_uj) coupling holds; the sealed JCR-1 envelope verifies under the committed steward key and matches the canonical core.

  • C4 — attestation. The core canonicalizes to the fixed JCS bytes and verifies under the committed supervisor key; the device classes match the receipt's.

  • C5 — tier minimization. Each grant set + flag combination resolves to the lowest satisfying tier (S0–S7).

  • C-neg — adversarial negatives. negative.json holds malformed artifacts a conformant host MUST reject: a HwShunt reading with no measured figure, an Estimator carrying one, a total that does not equal the device sum, a measured-coverage mismatch, an attestation that omits an accelerator the receipt metered (SPEC §7.2), an S6 attestation without TEE evidence (SPEC §7.6), a replay journal that diverges and one that is truncated (SPEC §8), and a mid-run grant-set mutation whose content address changes (SPEC §1.2). The harness asserts each is rejected or detectable.

  • C-tee — confidential + sovereign. confidential.json carries SEV-SNP report vectors — a valid report that verifies against policy + VCEK, plus negatives (wrong launch measurement, tampered body that fails the ECDSA-P384 signature) — and a hash-chained audit-log vector that must verify (SPEC §7.6, §7.7).

Negatives are what a standard certifies; growing this set (tier-minimization violations, anti-evasion probing) is the highest-value contribution here — see ../CONTRIBUTING.md.

Regenerating and verifying

cd ../sandbox-rs
cargo run -p sandbox-conformance --bin gen_vectors   # rewrite conformance/v1/*.json
cargo test -p sandbox-conformance                    # verify in-code + file-backed
cargo run -p sandbox-cli -- conformance              # human-readable pass/fail

Ed25519 signing is deterministic (RFC 8032), so the signatures are reproducible known answers: regenerating on an unchanged reference produces byte-identical files.