The Plan 9 Security Architecture

1. The Plan 9 Security Architecture Russ Cox, MIT LCS joint work with Eric Grosse, Rob Pike, Dave Presotto, Sean Quinlan Bell Labs, Lucent Technologies rsc@mit.edu

2. Outline • What is a security architecture? • What is Plan 9? • What did Plan 9 do right? • What did Plan 9 do wrong? • How did we fix it? • Conclusion

3. What is a security architecture? • An interface for applications to • authenticate users and services • establish secure channels • A mechanism to manage authentication secrets (keys) • Lots of code to implement cryptographic protocols and functions • OS protection: user ids, access permissions, etc.

4. Goals • Clarity • if a user doesn’t understand key management and how the system works, there’s not much security. • Ease of use • if security is hard to use, it won’t get used. • Decoupling of security from application code • security code is hard to get right. • fix problems without touching applications.

5. Systems approach • Security involves technology: protocols, math, etc. • not the focus today. • assume all this as fundamentals • Focus on how to deploy within OS context • must be integrated into environment (not ssh) • users will “work around” hard-to-use security

6. Outline • What is a security architecture? • What is Plan 9? • What did Plan 9 do right? • What did Plan 9 do wrong? • How did we fix it? • Conclusion

7. Plan 9 • Research OS developed at Bell Labs • development since late 1980s • base for other research since 1995 • Easy for us to work on: • we wrote and control all the source • simple design makes everything easier

8. Plan 9 principles • Every resource has a file-like name • One protocol, 9P, used by kernel to access remote or user-level resources • Each process has its own private, malleable name space

9. All resources are files • Examples /dev/time current time /net/ether0 ethernet device /net/tcp TCP network connections /env/path environment variable $path /dev/draw graphics device /mnt/wsys window system control files • Interfaces are usually textual

10. One file protocol, 9P • Simple, small protocol • 13 message types • easy to write new servers, filters

11. Name space • Resources gathered in hierarchical name space • Shared by all members of process group rfork(RFNAMEG) starts new process group • Changing the name space: mount(int fd, char *mtpt, int flags, char *name); bind(char *dir, char *mtpt, int flags); • Shell level % dial tcp!emelie!9fs /srv/emelie % mount /srv/emelie /n/emelie % bind /386/bin /bin % bind –a $home/386/bin /bin

12. Example: rio, the window system • Starts with kernel devices /dev/mouse, /dev/draw, /dev/screen, /dev/cons • Provides same interface to each client works because of per-process name spaces /dev/mouse always means “my mouse” • Client looks identical to server can run clients without window system can run rio inside itself (debugging, remote desktop)

13. Overall security model • User logs in to terminal • Types password, stored locally, used to authenticate remote services • Auth server holds secret information encrypted • Auth protocols use auth server to authenticate both sides of connection. • Auth protocol is part of 9P attach message • Occasionally, one user must authenticate for another user: the speaks for relation • Example: cpu command causes CPU server to connect to file server on behalf of the remote user

14. Host owner • Local machine resources owned by the host owner • normal user account • no a priori special privileges • on terminals, the user who booted the terminal • on CPU servers, a pseudo-user • Analogous to root but much weaker • only controls local resources • has no special powers outside its machine • cannot read everyone’s files, etc.

15. Outline • What is a security architecture? • What is Plan 9? • What did Plan 9 do right? • What did Plan 9 do wrong? • How did we fix it? • Conclusion

16. File permissions • All resources are files • Familiar model for access control: file permissions • alrwxrwxrwx, a is append-only, l is exclusive use • permissions enforced by servers, not kernel • system logs are a-rw-rw-rw- • no syslog daemon: programs write directly to log • mail spools are alrw--w--w- • to deliver mail, just open mailbox and write a message

17. Sandboxing • Since all resources are in name space, if we control name space we control resources untrusted user can see • Sandbox: construct a name space with only those resources the user should be able to access • Turn off the ability to make new network connections unmount("/net") • Turn off ability to add new local resources rfork(RFNOMNT) • Start user process

18. Advantages (so far) • System architecture provides a focus for design of security • Uniform way to provide access to resources leads to uniform way to control access. • File permissions • Name space manipulation • Sandboxing is easy and intuitively secure • No superuser

19. Outline • What is a security architecture? • What is Plan 9? • What did Plan 9 do right? • What did Plan 9 do wrong? • How did we fix it? • Conclusion

20. Problems (about to be fixed) • One security domain • can’t be rsc in one place and rcox in another • can’t have different passwords • Auth protocol hard-wired into 9P • fixing an auth bug would require redefining 9P • Auth code in all servers, clients, kernels • fixing an auth bug would require extensive code changes • Needham-Schroeder-like shared key authentication • passwords, DES keys too short: vulnerable to eavesdropper dictionary attack

21. Outline • What is a security architecture? • What is Plan 9? • What did Plan 9 do right? • What did Plan 9 do wrong? • How did we fix it? • Conclusion

22. Redesign around an agent – factotum • From the Oxford English Dictionary: • a. In L. phrases: Dominus factotum, used for ‘one who controls everything’, a ruler with uncontrolled power; Johannes factotum, a Jack of all trades, a would-be universal genius. Also fig. • b. One who meddles with everything, a busybody • c. In mod. sense: A man of all-work; also, a servant who has the entire management of his master’s affairs.

23. Factotum interface • This is Plan 9, so factotum is a file server % cd /mnt/factotum % ls –l -lrw------- … gre gre 0 Apr 17 13:47 confirm --rw-r--r-- … gre gre 0 Apr 17 13:47 ctl -lr-------- … gre gre 0 Apr 17 13:47 log -lrw------- … gre gre 0 Apr 17 13:47 needkey --r--r--r-- … gre gre 0 Apr 17 13:47 proto --rw-rw-rw- … gre gre 0 Apr 17 13:47 rpc %

24. Factotum overview • Factotum • holds keys • uses keys to execute authentication protocols • host owner’s factotum moderates identity changes on that machine • user can run his own factotum; programs use whatever is at /mnt/factotum • Secstore • provides a safe for holding keys • consulted by factotum to retrieve keys • Kernel • allows host owner’s factotum to issue identity change capabilities

25. Example boot sequence • Kernel starts, user logs in • user[none]: gre • User has account on local secstore server, so fetch factotum keys from secstore • secstore password: ********* • STA PIN+SecurID: ********* • Factotum uses keys to authenticate to other services (mail, file servers, VNC) during login

26. Keys • A key is a list of attribute=value pairs: proto=p9sk1 dom=cs.xyz.com user=gre !password=xyzzy confirm=yes proto=apop server=comcast.net user=gre12345 !password=boo • The ‘!’ prefix means “secret; don’t show this in key list” • Attributes are known either by • factotum itself – proto, confirm, owner • the protocols – password, user, server, dom • the user – anything else

27. Factotum and keys • Keys are added to factotum by writing them to the ctl file. % cd /mnt/factotum % cat >ctl key dom=bell-labs.com proto=p9sk1 user=gre !password=’don’’t tell’ key proto=apop server=x.y.com user=gre !password=’secret mail’ ^D % cat ctl key dom=bell-labs.com proto=p9sk1 user=gre !password? key proto=apop server=x.y.com user=gre !password? %

28. Key patterns • Key patterns are attribute=value pairs. • The key must be a superset of the pattern % cat ctl key dom=bell-labs.com proto=p9sk1 user=gre !password? key proto=apop server=x.y.com user=gre !password? % echo ’delkey proto=apop’ >ctl % cat ctl key dom=bell-labs.com proto=p9sk1 user=gre !password? %

29. Secstore • Secure, encrypted file store for small, precious files • a safe to hold keys • PAK protocol provides password-based access • hash password to yield auth key • actively attacking PAK is equivalent to computational Diffie-Hellman • File encryption/decryption performed by client • hash password another way to yield crypt key • if server is compromised, attacker must break individual files

30. Secstore and factotum • Factotum fetches file named factotum from secstore at boot time • assumed to hold initial set of keys user[none]: gre secstore password: ***** • can reload the secstore file into factotum at any time secstore –G factotum >/mnt/factotum/ctl • can edit the key file (fetch to ramfs, edit, put back) • User must remember only one password • can be fairly high entropy • stored keys can be arbitrarily high entropy

31. Factotum interface for programs • Authproxy executes RPCs over /mnt/factotum/rpc to proxy a conversation between factotum and a file descriptor. Attr *a; AuthGetkey *getkey; a = authproxy(fd, getkey, “proto=p9any role=client”); • Last argument is a key pattern, as a printf-style string: a = authproxy(fd, getkey, “proto=p9any role=client server=%s”, machine); • Attr holds attr=value results of authentication • user name and domain at other end • nonce keys for the conversation • possibly a capability to change user id

32. Identity changes via capabilities • User id changes are managed by capabilities • string oldname@newname@random-hex • allows a process running as oldname to become newname • single use • Host owner’s factotum issues capabilities by writing their SHA1 checksums to /dev/caphash echo rsc@rob@xyzzy | sha1sum >/dev/caphash • Factotum hands capability to another process, which then writes it to /dev/capuse echo rsc@rob@xyzzy >/dev/capuse • /dev/caphash is removed after the host owner’s factotum starts • other host owner processes can’t use it.

33. Unprivileged, safe servers • Servers run as none, the opposite of a superuser • can’t debug any processes • explicitly excluded from some file systems (e.g., dump) • (like everyone else,) requires a capability in order to become another user • Bugs in server are less critical • on Unix, servers run as root: breaking a server gives you full access • on Plan 9, servers run as none: breaking a server gives you hardly any access

34. New 9P • Need to decouple 9P from authentication protocol • Plan 9 is all about making everything look like files • so make 9P authentication look like reading and writing a file • auth open an auth file • read, write to execute protocol • attach no auth info but afid instead • … continue as before

35. Authentication in the new 9P • First connect to the file server: fd = dial(“tcp!emelie!9fs”); • Next use a system call to emit a message to create (and open) a one-time authentication file: afd = fauth(fd, “service”); • Then run the authentiation protocol over it: a = authproxy(afd, nil, “proto=…”); • Finally use afd in mount call mount(fd, afd, “/n/emelie”, MREPL, “service”);

36. Outline • What is a security architecture? • What is Plan 9? • What did Plan 9 do right? • What did Plan 9 do wrong? • How did we fix it? • Conclusion

37. Future • Connect factotum to web browser for access to web-hosted services • Port factotum to Unix and Windows • The cron problem • Get rid of speaks for: it makes cpu server host owner too special

38. Summary • A file-oriented approach to security • A secure place to keep your keys • A trusted agent to handle them • A clean way to separate security code from kernels, applications, etc. • Advantages: • easy to understand the model • easy to use • easy to change keys, protocols, implementations • More secure and easier to use.

39. Links • Plan 9 paper http://plan9.bell-labs.com/sys/doc/9.pdf • Security paper http://plan9.bell-labs.com/sys/doc/auth.pdf • Plan 9 distribution http://plan9.bell-labs.com/plan9 • Email rsc@mit.edu