Security in Plan 9

The Plan 9 Security Architecture
Russ Cox, MIT LCS
joint work with
Eric Grosse, Rob Pike,
Dave Presotto, Sean Quinlan
Bell Labs, Lucent Technologies
[email protected]
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?
What is a security architecture?
An interface for applications to
• authenticate users and services
• establish secure channels
A mechanism to manage authentication secrets
Lots of code to implement cryptographic
protocols and functions
OS protection: user ids, access permissions, etc.
• 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,
• 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
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?
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
current time
/net/ether0 ethernet device
TCP network connections
environment variable $path
graphics device
window system control files
Interfaces are usually textual
One file protocol, 9P
Simple, small protocol
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
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
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
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.
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?
File permissions
All resources are files
Familiar model for access control: file
• 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
Since all resources are in name space, if we control
name space we control resources untrusted user can
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
Turn off ability to add new local resources
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
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?
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
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?
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
Factotum overview
• holds keys
• uses keys to execute authentication protocols
• host owner’s factotum moderates identity changes on that
• user can run his own factotum; programs use whatever is at
• provides a safe for holding keys
• consulted by factotum to retrieve keys
• allows host owner’s factotum to issue identity change
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
A key is a list of attribute=value pairs:
proto=p9sk1 user=gre
!password=xyzzy confirm=yes
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 proto=p9sk1 user=gre
!password=’don’’t tell’
key proto=apop user=gre
!password=’secret mail’
% cat ctl
key proto=p9sk1 user=gre !password?
key proto=apop user=gre !password?
Key patterns
Key patterns are attribute=value pairs.
The key must be a superset of the pattern
% cat ctl
key proto=p9sk1 user=gre !password?
key proto=apop user=gre !password?
% echo ’delkey proto=apop’ >ctl
% cat ctl
key proto=p9sk1 user=gre !password?
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
File encryption/decryption performed by client
• hash password another way to yield crypt key
• if server is compromised, attacker must break individual
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
Attr *a;
AuthGetkey *getkey;
a = authproxy(fd, getkey, “proto=p9any
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 [email protected]@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 [email protected]@xyzzy | sha1sum >/dev/caphash
Factotum hands capability to another process, which
then writes it to /dev/capuse
echo [email protected]@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
read, write
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”);
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?
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
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.
• easy to understand the model
• easy to use
• easy to change keys, protocols, implementations
More secure and easier to use.
Plan 9 paper
Security paper
Plan 9 distribution
[email protected]

similar documents