Lecture 15: Multics for the Masses

1. Lecture 15: Multics for the Masses There once was an artist named Titian Who worked like a future Multician. With models ramshackle, He’d just change their ACL, And give them all access permission. Peter Neumann David Evans http://www.cs.virginia.edu/~evans CS551: Security and Privacy University of Virginia Computer Science

2. Menu • Midterm Results • Introduction to the Rest of the Course • Saltzer & Schroeder – “The Protection of Information in Computer Systems” • Return Midterms University of Virginia CS 551

3. Midterm • Most people did well • I don’t grade on a curve (but the histogram is provided to give you a sense of how you did) • Don’t misinterpret the , , or cross-country skieras an indication of your likely final grade: • Everyone can still get an A in the course • Anyone can still fail the course University of Virginia CS 551

4. Problem 4 (2): Faculty Turnover • Best solutions based on S-Key • Card issuer generates random number R for each door, calculates h(R), h(h(R), ..., h1001 (R). • Initializes door with h1001 (R). • The first card gets h1000 (R). Next card gets h999 (R), h998 (R), etc. University of Virginia CS 551

5. No h(h(v)) h = Yes Open Door No Alert Security! Card Reader Memory: hn+1 (R) Value from card h(v) h = Yes Open Door Store h(v) in memory University of Virginia CS 551

6. System Security University of Virginia CS 551

7. Course Overview • Part 1 (until now): • Making/breaking the numeric keypad • Almost all math • Part 2 (rest of course): • Making/Kicking down the door • Mostly engineering and people (but math is still important) University of Virginia CS 551

8. Learning in CS551 University of Virginia CS 551

9. Anonymous Poll: How many read S&S? University of Virginia CS 551

10. Rest of Course • Saltzer/Schroeder papers describes state of the art in security in 1974 • Based on work on Multics (predecessor to UNIX, but better) • Are things better or worse today? University of Virginia CS 551

11. Laws of Inevitable Progress • Moore’s Law: • Processing power doubles every 18 months • Gates’ Law • Software grows to use all available memory and processing power • Ex: • Multics 1969: 56,000 lines of code (PL/I) • Windows 2000: ~55M lines of code (asm/C/C++) • 1000x in 30 years (law predicts 1Mx, so uSoft has work to do!) University of Virginia CS 551

12. Bugs and Vulnerabilities • Neumann’s (?) Law: • Number of bugs increases as square of code size • Security vulnerabilities are approximately linear in the number of program bugs (lots of other things cause vulnerabilities too) • Windows 2000 has 965,000 times as many bugs as Multics. • Double because of C++ ~ 2M times as many security vulnerabilities. University of Virginia CS 551

13. Motivation • Metcalfe’s Law: • Value of a network is square of number of users • Internet growth: • 1974: ~1000 hosts (10000 users?) • 2000: 200 M users • Internet is 400M times more valuable today than it was in 1974 University of Virginia CS 551

14. The Bad News • Unnamed Law: • Security risk is the product of the number of vulnerabilities (linear in the number of code bugs) and the value (how many people will be motivated how hard to attack you) Multics in 1974: (56K)2 * (10K)2 Windows 2000: (55M * 2)2 * (200M)2 • Security problems are 1.54*1015 times (quadrillion) worse today than in 1974! University of Virginia CS 551

15. The Good News • Some small technical improvements since 1974 – firewalls, intrusion detection, virus scanners (no viruses in 1974) (The Really Good News) • This means security people are much in demand and obscenely well paid. University of Virginia CS 551

16. Prehistory • Security didn’t matter much when you had batch processing and machine operators • CTSS (1961, Fernando Corbató) – Compatible Time-Sharing System • First time-sharing operating system • Each user’s job has access to full machine in turn • 1962 demo to ARPA led to $3M funding for Project MAC University of Virginia CS 551

17. History • Multics – “Multiplexed Information and Computing Service” (1969, Corbató, Saltzer) • Design goals: http://www.multicians.org/managerial.html • Convenient remote terminal use. • Continuous operation (i.e., without shutdown) analogous to power and telephone companies. • A wide range of configuration capacity which could be dynamically varied without system or user program reorganisation. University of Virginia CS 551

18. Multics Design Goals, Cont. • An internal file system with apparent reliability high enough for users to entrust their only copies of programs and data to it. • The ability of users to share selectively information among themselves. • The ability to store and create hierarchical structures of information for purposes of system administration and decentralisation of user activities. First hierarchical file system! University of Virginia CS 551

19. Multics Design Goals, cont. • The ability to support a wide range of applications ranging from heavy numerical production calculations to inter active time-sharing users without inordinate inefficiency. • The ability to allow a multiplicity of programming environments and human interfaces within the same system. • The ability to evolve the system with changes in technology and in user aspirations. Multics more-or-less achieved all of these with 54.94M less lines of code than Windows 2000! University of Virginia CS 551

20. S & S Definitions • Privacy – “The ability of an individual to decide whether, when, and to whom personal information is released.” • Security – “Used to denote mechanisms and techniques that control who may use or modify the computer or the information stored in it.” • Reading (confidentiality) • Writing (integrity) • Availability University of Virginia CS 551

21. Multiple Use Systems • Computer with more than one purpose • 1975: mainframes, time-sharing • 2000: networked PCs • One machine is shared by people and programs who don’t trust each other completely. University of Virginia CS 551

22. Levels of Information Protection • All-or-Nothing Systems • Complete isolation • No sharing, like pulling out network cable • Controlled (Static) Sharing • Different people can access each item • UNIX: user/group IDs, mode bits • NFS: access control lists University of Virginia CS 551

23. Levels of Information Protection 2 • Programmable Sharing Controls • Two users must agree to modification • Access only between 2am and 6am • Implementation techniques: • Reference monitors • Capabilities University of Virginia CS 551

24. S&S Principles 1 • Economy of Mechanism – keep it (small and) simple stupid! • Fail-safe defaults – make permission active instead of exclusion • Complete mediation – every access to every object is checked • Open design – don’t rely on security by obscurity. University of Virginia CS 551

25. S&S Principles 2 • Separation of privilege – require two separate checks/keys for permission • Least privilege – allow as little access as possible for job • Least common mechanism – don’t share mechanisms between users • Psychological acceptability – don’t confuse users or drive them crazy University of Virginia CS 551

26. S&S Principles: Conflicts? • Economy of Mechanism vs. Least Common Mechanism • Fail-safe defaults vs. Psychological Acceptability • Separation of Privilege vs. Economy, Psychological Acceptability • Least privilege vs. Psychological Acceptability • etc. University of Virginia CS 551

27. No h h(h(v)) How well does this satisfy S&S Principles? Card Reader Card Issuer R, n Memory: hn+1 (R) Value from card h = h(v) Open Door Yes Key Card hn (R) = Yes Open Door Store h(v) in memory No Alert Security! University of Virginia CS 551

28. Virtual Memory Protection Memory Processor Program 2 Descriptor Register: base bound Program 1 Privileged state bit: off bound base address Processor checks all memory references according to base and bound. Cannot change unless privileged state bit is on (only for Supervisor). Supervisor University of Virginia CS 551

29. Limitations of Virtual Memory • Cannot share memory between programs • Can add additional descriptors to set up shared memory, add read/write bits, etc. • Requires special hardware • Software Fault Isolation [Wahbe96] can do it in software only • Performance cost for every memory access University of Virginia CS 551

30. Capabilities • User places protection descriptor values (“capabilities”) on memory addresses • Allows for arbitrary, controlled memory sharing • Capabilities can refer to hardware devices also (they are just memory addresses) • Need to make capabilities unforgeable • Hardware-protected tags • (~ Java – type-checking + bytecode verification) University of Virginia CS 551

31. Capabilities Problems: Revocation • Once someone has a capability, how can you deny access? • Must destroy original object • Java: once someone has an open FileOutputStream, can’t revoke it! • No cheap solution: • Store capabilities somewhere special and disallow copying • Require an indirection step through something object owner controls University of Virginia CS 551

32. Capabilities Problems: Propagation • How can you control who capability is passed to? (You can’t.) • Java: can’t control which applet that FileOutputStream is passed to • Possible solutions: • Store somewhere special and disallow copying (passing as parameters) • Associate capability with principal (need to check call stack) University of Virginia CS 551

33. Access Control Lists • Maintain a list of principals and access permissions • Delay check until last possible moment (can “revoke” until then) • Access controlled must be protected • Combine with capabilities to avoid having to check table for every memory reference University of Virginia CS 551

34. Multics Rings Ring 8 Untrusted User Programs Lower rings have more privileges. Memory segments have descriptors that indicate highest ring number that may read/write segment. Special instructions for switching between rings (e.g., making a system call). Ring 2 Ring 1 Ring 0: Kernel University of Virginia CS 551

35. Summary • Computers may be ~1M times faster than 1970, but they are >1 Quadrillion times less secure! • Multics was way better than Windows 2000 • Basic confidentiality and integrity mechanisms from early 1970s still dominate today, and more or less work. Hard part is: • Designing and defining good policies • Implementing software without bugs University of Virginia CS 551

36. Charge • Now is the time to get cracking on your projects. If you are unsure what to do, meet with me. • I brushed over all the details on capabilities and ACLs: read S&S • Do the readings! • Next time: Viruses, Worms, Trojan Horses, and all that good stuff! University of Virginia CS 551