The Confused Deputy =================== What kind of paper is this? Kind of a marketing story "This is a nearly true story"--not very scientific Author is arguing for capabilities--a somewhat fringe technology Has significant experience with capabilities Worked on capability system GNOSIS at Tymshare in the 70s Went on to build KeyKOS system at Key Logic Writing as senior architect of company that sells KeyKOS Published in OSR, non peer-reviewed newsletter reaching OS researchers What is Tymshare, the company where this story is set? Paper published in 1988, events 11 years earlier means ca. 1977 "provided commercial timesharing services" So customers people paid to have shell accounts on machines used by others Sounds like some kind of usage-based charging, tracked in (SYSX)BILL What is an "access list architecture"? Each object (e.g., file) has list of who can access it Today, would call this an "access control list" or ACL architecture By contrast, in capabilities permissions are stored with the subject E.g., a process has a list of capabilities for files What went wrong at Tymshare? Wanted to track language feature usage in fortran compiler (SYSX)FORT So modified compiler to keep statistics in (SYSX)STAT. Specifically: (SYSX)FORT should write to (SYSX)STAT no matter who runs compiler (SYSX)FORT should also write output files as directed by the user But since user is specifying output file, should be writable by user Compiler "deputised" to write to anything in (SYSX) by "home files license" Also "deputised" by user to write its output file And what if use specifies output file in (SYSX), e.g., (SYSX)BILL? Compiler happily clobbers BILL file Is there an easy fix for a access list architecture? Top of p. 37: Every time we added a clause enabling the opening of a file in a categorical situation we would introduce security problems in programs that had been secure. Every time we added restrictions to these categories we broke other legitimate programs. The last time that I wrote down the requirements for a program to open a file, it required fourteen boolean operators... Middle of p. 37: new system call to "switch hats" But eventually needed more than two hats, or didn't extent to non-files How do capabilities solve the problem? Merges naming and authority: The capability both identifies the file and authorizes the compiler to write there. When producing the debugging output the compiler would merely refer to a capability provided by the invoker to the place he meant to hold that output. The same mechanism is used in each case--no ASCII character names are required, no authority checking mechanisms are executed. What is the Trojan horse problem, and how do capabilities help? Run a program to do one thing (e.g., edit a file) Program surreptitiously does something else (e.g., modifies different file) Capabilities help subjects grant only minimal permissions to others Analogy valet parking: Give valet just the key to your car Don't hand over keys to your house, credit cards, etc., as well What is the "mutually suspicious users problem"? One user writes a program, wants to keep code secret Another user wants to run the program on data, but keep the data secret Do capabilities really help with this? KeyKOS has unique solution of "factories" A factory lets invoker create a process But guarantees process has no inherent capabilities Hence can only communicate via capabilities invoker gives Permits isolation of processes