The Plan 9 Security Architecture

Russ Cox, MIT LCS

joint work withEric Grosse, Rob Pike,

Dave Presotto, Sean QuinlanBell 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/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

One file protocol, 9P

attach get handle for file system rootwalk descend the hierarchystat

wstat

open

read

write

clunk throw away a handle

Simple, small protocol

13 message types• easy to write new servers, filters

Name space

Resources gathered in hierarchical name spaceShared 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 clientworks because of per-process name spaces

/dev/mouse always means “my mouse”

Client looks identical to servercan 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 filesFamiliar 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

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 connectionsunmount("/net")

Turn off ability to add new local resourcesrfork(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 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%

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=yesproto=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 >ctlkey 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 ctlkey 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 ctlkey 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 ctlkey 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]: gresecstore password: *****

• can reload the secstore file into factotum at any timesecstore –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/caphashecho rsc@rob@xyzzy | sha1sum >/dev/caphash

Factotum hands capability to another process, which then writes it to /dev/capuseecho 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 open an auth file

read, write to execute protocol

attach 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 callmount(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 securityA secure place to keep your keysA trusted agent to handle themA 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 paperhttp://plan9.bell-labs.com/sys/doc/9.pdf

Security paperhttp://plan9.bell-labs.com/sys/doc/auth.pdf

Plan 9 distributionhttp://plan9.bell-labs.com/plan9

Emailrsc@mit.edu