The Plan 9 Security Architecture Russ Cox MIT

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

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

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.

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.

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

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

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

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

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

One file protocol, 9 P Simple, small protocol attach walk stat wstat open read write clunk get handle for file system root descend the hierarchy throw away a handle 13 message types • easy to write new servers, filters

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!9 fs /srv/emelie mount /srv/emelie /n/emelie bind /386/bin bind –a $home/386/bin

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)

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 9 P 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

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.

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

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-rwno syslog daemon: programs write directly to log mail spools are alrw--w--wto deliver mail, just open mailbox and write a message

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

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

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

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 9 P • fixing an auth bug would require redefining 9 P 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

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

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.

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

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

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+Secur. ID: ***** Factotum uses keys to authenticate to other services (mail, file servers, VNC) during login

Keys A key is a list of attribute=value pairs: proto=p 9 sk 1 dom=cs. xyz. com user=gre !password=xyzzy confirm=yes proto=apop server=comcast. net user=gre 12345 !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

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=p 9 sk 1 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=p 9 sk 1 user=gre !password? key proto=apop server=x. y. com user=gre !password? %

Key patterns are attribute=value pairs. The key must be a superset of the pattern % cat ctl key dom=bell-labs. com proto=p 9 sk 1 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=p 9 sk 1 user=gre !password? %

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

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

Factotum interface for programs executes RPCs over /mnt/factotum/rpc to proxy a conversation between factotum and a file descriptor. Authproxy Attr *a; Auth. Getkey *getkey; a = authproxy(fd, getkey, “proto=p 9 any role=client”); Last argument is a key pattern, as a printf-style string: a = authproxy(fd, getkey, “proto=p 9 any 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

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 SHA 1 checksums to /dev/caphash echo rsc@rob@xyzzy | sha 1 sum >/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.

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

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

Authentication in the new 9 P First connect to the file server: fd = dial(“tcp!emelie!9 fs”); 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”);

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

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

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.

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