#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.
#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