The Plan 9 Security Architecture

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
• rsc_at_mit.edu

2
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
• if a user doesnt understand key management and
  how the system works, theres not much security.
• Ease of use
• if security is hard to use, it wont 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
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
• 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

• Simple, small protocol
• 13 message types
• easy to write new servers, filters

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 everyones files, etc.

15
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
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
• cant be rsc in one place and rcox in another
• cant 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
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
  masters 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 1347 confirm
• --rw-r--r-- gre gre 0 Apr 17 1347 ctl
• -lr-------- gre gre 0 Apr 17 1347 log
• -lrw------- gre gre 0 Apr 17 1347 needkey
• --r--r--r-- gre gre 0 Apr 17 1347 proto
• --rw-rw-rw- gre gre 0 Apr 17 1347 rpc

24
Factotum overview

• Factotum
• holds keys
• uses keys to execute authentication protocols
• host owners 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 owners factotum to issue identity
  change capabilities

25
Example boot sequence

• Kernel starts, user logs in
• usernone gre
• User has account on local secstore server, so
  fetch factotum keys from secstore
• secstore password
• STA PINSecurID
• Factotum uses keys to authenticate to other
  services (mail, file servers, VNC) during login

26
Keys

• A key is a list of attributevalue pairs
• protop9sk1 domcs.xyz.com usergre
• !passwordxyzzy confirmyes
• protoapop servercomcast.net
• usergre12345 !passwordboo
• The ! prefix means secret dont 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 gtctl
• key dombell-labs.com protop9sk1 usergre
• !passworddont tell
• key protoapop serverx.y.com usergre
• !passwordsecret mail
• D
• cat ctl
• key dombell-labs.com protop9sk1 usergre
  !password?
• key protoapop serverx.y.com usergre !password?

28
Key patterns

• Key patterns are attributevalue pairs.
• The key must be a superset of the pattern
• cat ctl
• key dombell-labs.com protop9sk1 usergre
  !password?
• key protoapop serverx.y.com usergre !password?
• echo delkey protoapop gtctl
• cat ctl
• key dombell-labs.com protop9sk1 usergre
  !password?

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
• usernone gre
• secstore password
• can reload the secstore file into factotum at any
  time
• secstore G factotum gt/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, protop9any
  roleclient)
• Last argument is a key pattern, as a printf-style
  string
• a authproxy(fd, getkey, protop9any
  roleclient servers, machine)
• Attr holds attrvalue 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 oldname_at_newname_at_random-hex
• allows a process running as oldname to become
  newname
• single use
• Host owners factotum issues capabilities by
  writing their SHA1 checksums to /dev/caphash
• echo rsc_at_rob_at_xyzzy sha1sum gt/dev/caphash
• Factotum hands capability to another process,
  which then writes it to /dev/capuse
• echo rsc_at_rob_at_xyzzy gt/dev/capuse
• /dev/caphash is removed after the host owners
  factotum starts
• other host owner processes cant use it.

33
Unprivileged, safe servers

• Servers run as none, the opposite of a superuser
• cant 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
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
• 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_at_mit.edu