SHM threat model (ByteOr OSS)
Synced from repo docs
This page is synced from docs/policy/shm-threat-model.md via docs/public-docs.json. Edit the owning repo source instead of this generated copy. GitHub source: https://github.com/byteor-systems/byteor/blob/master/docs/policy/shm-threat-model.md
ByteOr's SHM path is designed for high-throughput local IPC, not as a trust boundary by itself.
Trust model
- Shared-memory files and headers are untrusted input until validated.
- ByteOr relies on normal OS file permissions and process isolation; it does not create a new security boundary stronger than the host/user model already provides.
- The intended baseline is cooperating processes on the same host with least-privilege filesystem access.
What ByteOr defends against
The OSS SHM path is designed to detect and reject common local hazards such as:
- malformed or truncated headers
- stale files from previous runs
- layout/version/capability mismatch
- half-initialized mappings after crashes
The runtime should fail closed on those conditions rather than continue with undefined behavior.
What ByteOr does not promise
The OSS workspace does not promise:
- confidentiality against a local principal that can already read the SHM directory
- durable crash recovery from arbitrary file corruption
- distributed replication or consensus-backed recovery
- safe execution of data from an attacker-controlled host environment without ordinary OS hardening
Operator guidance
- Use restrictive permissions on the SHM directory.
- Run processes with the minimum privileges they need.
- Treat leftover mapping files after crashes as cleanup artifacts, not trustworthy state.
- Prefer explicit cleanup/recreate over trying to reuse suspicious artifacts.