#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