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

2. What is a security architecture?
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 Ease of use Decoupling of security from application code
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. What is a security architecture?
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 Easy for us to work on:
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 get handle for file system root
Simple, small protocol
13 message types
easy to write new servers, filters
attach
get handle for file system root
walk
descend the hierarchy
stat
wstat
open
read
write
clunk
throw away a handle

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. What is a security architecture?
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. What is a security architecture?
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. What is a security architecture?
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 Secstore Kernel 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 %

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
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 | sha1sum >/dev/caphash
Factotum hands capability to another process, which then writes it to /dev/capuse
echo >/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. What is a security architecture?
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 Security paper Plan 9 distribution Email
Security paper
Plan 9 distribution