Memory and Swap Artifacts (HARD-MEM)

Validate that sandbox runtime memory does not leak to operating system artifacts such as pagefile/swap, hibernation files, crash dumps, or post-termination residue. You ensure that sensitive data handled inside the Secure Sandbox runtime cannot be recovered from host-level memory persistence mechanisms.

Objectives

• Prevent leakage of sandbox memory contents into pagefile.sys/swap files.
• Deny or sanitize crash/heap dumps of sandboxed processes.
• Block hibernation persistence while sensitive sandbox workloads run, or ensure encryption renders artifacts unrecoverable.
• Ensure post-termination memory cannot be recovered via host memory forensics.

Controls Under Test

• Virtual memory paging: Windows pagefile.sys, Linux swap file/partition, macOS swapfiles.
• Hibernation persistence: Windows hiberfil.sys, macOS sleepimage.
• Crash dump creation: WER minidumps/full dumps, kernel dumps, user-mode dump tools (for example, procdump, createdump, gcore).
• Memory reclamation on sandbox termination and artifact scrubbing/at-rest encryption.

Test Scenarios

ID	Threat / Scenario	Universal Procedure	Expected Outcome & Audit
HARD-MEM-01	Pagefile/swap leakage of sandbox secrets	1. In a sandboxed process, allocate a buffer and fill with a unique marker (for example, HARD_MEM_TEST_01_{{GUID}}). 2. Apply memory pressure inside the sandbox to encourage paging (open large buffers/files). 3. Acquire the host paging artifact for offline analysis: Windows pagefile.sys; Linux swap file/partition; macOS swapfiles. 4. Search the artifact for the marker using a forensic-safe method (hash of marker, then literal).	Pass: Marker not present in pagefile/swap artifacts; sandbox memory is not persisted or is encrypted-at-rest and unrecoverable. Audit: category: device or runtime (implementation-specific), action: process (paging protected) or deny (paging attempts blocked), rule.id (memory protection policy), integrity.hash present.
HARD-MEM-02	Hibernation file contains sandbox memory	1. Start a sandboxed process with the unique marker in memory. 2. Trigger system hibernation while the sandbox is active. 3. Resume and copy hiberfil.sys (Windows) or the platform sleep image for offline analysis. 4. Search for the marker.	Pass: Marker not present; hibernation persistence is blocked while sandbox is active, or artifacts are protected (for example, volume encryption/policy) and unrecoverable. Audit: category: device, action: deny when hibernation is blocked, reason: "hibernationBlocked" (or equivalent), rule.id, integrity.hash.
HARD-MEM-03	Crash dumps reveal sandbox memory	1. With the marker in memory, attempt to create a dump of the sandboxed process using a generic dumper (for example, procdump -ma <pid> or platform-native crash reporting). 2. If the OS generates a dump, inspect for the marker; if denied, capture the denial event.	Pass: Dump creation is denied OR any generated dumps are sanitized/encrypted so the marker is not present. Audit: category: device or authz, action: deny (dump blocked) or process (sanitized), `reason: "dumpBlocked"
HARD-MEM-04	Post-termination memory residue	1. Populate the marker in a sandboxed process and then terminate the sandbox/session. 2. Acquire a host memory snapshot or permissible artifact (for example, paging file after termination). 3. Search for the marker.	Pass: Marker not present; sandbox memory was zeroed or is not accessible post-termination. Audit: If the platform emits a lifecycle event, require category: runtime, action: process, event: "sandboxTerminated", rule.id (lifecycle policy when applicable), integrity.hash.

Evidence Requirements

• Golden fields: category, action, rule.id, integrity.hash.
• Recommended fields: artifact.type (pagefile | swap | hiberfile | dump | memorySnapshot), artifact.path, bytesSearched, markerFound (false on pass), reason when a denial occurs (for example, hibernationBlocked, dumpBlocked).

Troubleshooting

• Ensure you are testing on the intended platform artifact (for example, correct swap file/partition). Some systems rotate or stripe swap across multiple files.
• Volume encryption may mask artifacts at rest; validate the encryption posture before concluding on memory protections alone.
• If dump tools succeed, verify that sandbox policies controlling dump/attach/debug are enabled and that tests use a process actually running inside the Secure Sandbox runtime.
• For hibernation tests on managed endpoints, coordinate carefully; forced hibernation may disrupt other services.

Known Limitations & Negative Space

• Kernel crash dumps and full physical RAM captures obtained with privileged incident response tooling may contain unrelated host data; this suite focuses on preventing sandbox memory artifacts specifically.
• Covert channels and microarchitectural leakage are out of scope for these procedures.