Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Plan 9 Security Architecture Russ Cox, MIT LCS joint work with Eric Grosse, Rob Pike, Dave Presotto, Sean Quinlan Bell Labs, Lucent Technologies

Similar presentations


Presentation on theme: "The Plan 9 Security Architecture Russ Cox, MIT LCS joint work with Eric Grosse, Rob Pike, Dave Presotto, Sean Quinlan Bell Labs, Lucent Technologies"— Presentation transcript:

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 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 attach get handle for file system root walk descend the hierarchy stat wstat open read write clunk throw away a handle 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 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 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 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; 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 >ctl key dom=bell-labs.com proto=p9sk1 user=gre !password=dont 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 % cat ctl key dom=bell-labs.com proto=p9sk1 user=gre !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 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 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 | 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 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 Security paper Plan 9 distribution


Download ppt "The Plan 9 Security Architecture Russ Cox, MIT LCS joint work with Eric Grosse, Rob Pike, Dave Presotto, Sean Quinlan Bell Labs, Lucent Technologies"

Similar presentations


Ads by Google