# Plan 9 Threat Model

## What Plan 9 Handles Well

- **Protocol-level attacks**: centralized in factotum, easy to update
- **Privilege escalation via compromised services**: capability system limits damage
- **Key distribution**: secstore + factotum, keys never leave volatile memory
- **Passive eavesdropping**: TLS on all modern connections
- **Process isolation**: per-process namespaces by default

## What Plan 9 Does NOT Handle

Must address at network/physical layer:

- **Physical machine compromise**: cold boot attacks extract volatile keys
- **Host owner debugging**: can debug any process via /proc
- **TCP reset attacks**: accepted as tolerable given randomized sequence numbers
- **No native packet-filtering firewall**: use external firewall/VLAN isolation
- **No intrusion detection**: use snoopy manually, or external IDS on VLAN boundary
- **DDoS**: handle at network perimeter

## Design Philosophy

Plan 9 does not rely on firewalls:

> "Firewalls require special code for every service penetrating the wall; the Plan 9 approach permits authentication to be done in a single place -- 9P -- for all services."

However, on a mixed network with Linux, add network-level isolation anyway.

## Known CVEs

Very few on record. Small, auditable codebase by expert programmers.
- CVE-2024-8158: lib9p auth bypass in hjfs (fixed in 9front)
- Full history: https://www.cvedetails.com/vulnerability-list/vendor_id-6177/product_id-10464/Bell-Labs-Plan-9.html

## Forks

- **9front**: only actively maintained fork with ongoing security work. Use this.
- **Harvey OS**: development stalled 2023, succeeded by "r9" project
- **Jehanne**: fork of Harvey with 9k kernel + 9front userland, no specific security improvements