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 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
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
All resources are files
Examples
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
/dev/time
Interfaces are usually textual
One file protocol, 9P
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!9fs /srv/emelie
mount /srv/emelie /n/emelie
bind /386/bin /bin
bind –a $home/386/bin /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 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
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 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
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 gre
--rw-r--r-- … gre gre
-lr-------- … gre gre
-lrw------- … gre gre
--r--r--r-- … gre gre
--rw-rw-rw- … gre gre
%
0
0
0
0
0
0
Apr
Apr
Apr
Apr
Apr
Apr
17
17
17
17
17
17
13:47
13:47
13:47
13:47
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+SecurID: *********
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=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
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?
%
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?
%
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
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
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.
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 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
read, write
attach
…
open an auth file
to execute protocol
no auth info but afid instead
continue as before
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”);
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://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