1 / 21

Chapter 3

Multics. Chapter 3. Chapter Overview. Multics contribution to technology Multics History Multics System Fundamentals Security Fundamentals Protection System Models Protection System Reference Monitor Multics Security Multics Vulnerability Analysis. Multics Contribution to Technology.

harriet-pittman
Download Presentation

Chapter 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multics Chapter 3

  2. Chapter Overview • Multics contribution to technology • Multics History • Multics System • Fundamentals • Security Fundamentals • Protection System Models • Protection System • Reference Monitor • Multics Security • Multics Vulnerability Analysis

  3. Multics Contribution to Technology • Segmented and Virtual Memory • Shared Memory multiprocessing • Hierarchical file systems • Online reconfiguration • Reference Monitor • Protection Systems • Protection Domain Transitions • Multilevel Security Policies

  4. Multics History • Began in 1963, based on a CTSS demo in 1961 (MIT, Fernando Corbató). Sponsored by ARPA under project MAC. • Supposedly, IBM was not interested in Paging/segmentation, so GE 645 was chosen instead. • Bell Labs joined project in 1965. • Multics was not self-hosting until 1968. • 1969: ARPA considered dropping project; Bell Labs dropped as well. • Multics turned out to be bigger, slower and less reliable than planned. • Honeywell purchased Computer division of GE in 1970. • Multics was commercialized 1973-1985, in use until 2000.

  5. Multics Fundamentals • Fundamental concepts: • Processes (executable context: run code) • Segments: files, I/O devices, etc.. • Organized into a hierarchy of directories and segments. • Protection domain of a process = segments it can access, together with the operations that it can perform on those segments. • Segments in the process's context have a set of segment descriptor words (SDWs). • Segments outside the process's context must be addressed by full name.

  6. Multics Security Fundamental Concepts • Supervisor: core Multics component, part of TCB. • Protection rings: a hierarchical layering, from most privileged (ring 0), where the most privileged code in the supervisor runs, to ring 63. 8 Were implemented in hardware, the rest were implemented with software tricks. • Ring 0 included access control, I/O, scheduling, segmentation and memory management. • Ring 1 included such things as accounting, stream management and file system search.

  7. The login process • Handled by process called answering service. • Answering service retrieves password segment to verify password (authorized by supervisor). • If user and password match, a process is created with the appropriate code and data segments, and perhaps the appropriate SDW's.

  8. The Multics login authorization process.

  9. A Segment Descriptor Word

  10. The Multics Protection System Models • There are three, different, interacting protection models in Multics: • Access control lists • Rings and Brackets • Multilevel Security • Access is granted if all three models grant it. • Details follow.

  11. Access Control Lists • Each segment and each directory has associated an ACL, stored in the parent directory. • Permissions are r(ead), w(rite), e(xecute) for segments and (check )s(tatus of entry), m(odify entry), or a(ppend an entry). To change the ACL, m permission is need on the parent directory. Format: perms user(s) (can be wildcarded): e.g. rwe Backup.SysDaemon.*

  12. Rings and Brackets • Each process runs in a certain ring r. • Each segment has three ring numbers associated with it: r1 ≤ r2 ≤ r3. • Segment access is determined by r, r1 and r2. • Segment execution is determined by r, r1, r2 and r3.

  13. Ring Policy for segment access • If r < r1 the process can read and write the segment. • If r1 ≤ r ≤ r2 the process can only read the segment. • If r2 < r Then no access allowed.

  14. Ring policy for segment execution • If r < r1 execution allowed, but there is a ring transition to an r', r1 ≤ r' ≤ r2, specified by the segment. • If r1 ≤ r ≤ r2, execution allowed, no ring transition. • If r2 < r ≤ r3 execution may be allowed if authorized by the gates in code segment's SDW; in this case there is a ring transition to r'. • If r3 < r, execution is not allowed.

  15. Multilevel Security • Subjects and objects are placed in levels so that the level of an subject and the level of any object can be compared to one another. (The higher the level the “more secret” it is) • Reading and writing is constrained so that information can flow from less secrecy to more secrecy: read below and write above rules.

  16. The Multics Protection System • The three protection policies are all checked: • For reading and writing, all three policies must grant access. • Execution is handled similarly; for MLS, there is a check for whether the process can read the segment. Note that that a ring transition may take place. • ACL and ring bracket policies are discretionary; MLS is a mandatory access policy loaded at boot time.

  17. The Multics Reference Monitor • Since each Multics instruction involved a segment either through a directory or through an SDW, each instruction was checked, eventually by the hardware. • Supervisor also: • Performed protection domain transitions • Protected processes during domain transitions: • parameter correctness when going to a lower ring, (checked by gatekeeper) • non-leakage of information when returning data to a higher ring. (usually through a return gate) • Maintains stack of return gates.

  18. Multics Security Evaluation 1 • Complete Mediation: Are all security-sensitive operations mediated correctly? • Yes, TOCTTOU attacks prevented by restricting directories to contain segments of only one access class. • Complete Mediation: All system resources security-sensitive operations mediated? • Not complete: Master Mode allowed code to run in a higher ring level without a full ring transition. • Complete Mediation Verification: Ring transitions and segment addresses are mediated correctly (straightforward to check). But operation complexity complicated matters: addressing complexity resulted in mediation errors.

  19. Multics Security Evaluation 2 • Tamperproof: Is the reference monitor protected? • The reference monitor is at level 0, which can only be entered through gatekeepers (and later through master mode). • Tamperproof: Does the protection system protect the TCB? • The TCB (huge) included services in rings 1-3. • Since ring bracket policy is discretionary, it can be modified by any process with the appropriate privileges

  20. Multics Security Evaluation 3 • Verifiable: What is the basis for the correctness of the system's TCB? • Too big to verify. • Verifiable: Does the protection system enforce the system's security goals? • MLS is good. • Ring protection can be corrupted, and ring assignment is somewhat arbitrary. • Ring transitions may be questionable.

  21. Multics Vulnerability Analysis (Paul Karger and Roger Schell, 1974) • Hardware vulnerability: a specific indirect addressing format was not checked. • Master Mode: signalers (i.e. interrupt handlers) running in master mode at the user level. • Further compromises allowed: • Take control of the patch utility • Forge the userid of processes • Modify the password file • Hide the existence of the attacker by modifying the audit trail and installing backdoors.

More Related