1 / 17

Protection and Control of Information Sharing in Multics

Explore the key innovation of Unix and the protection mechanisms implemented in Multics, including hierarchical access control lists, user authentication, and memory protection. Learn about design principles and weaknesses in the system.

rdewey
Download Presentation

Protection and Control of Information Sharing in Multics

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. G22.3250-001 Protection and the Control ofInformation Sharing in Multics Robert Grimm New York University

  2. Last Time: Unix • What is the key innovation of Unix? • Unified I/O: Files, pipes, sockets all use the same API • What other important feature offers considerable power? • Inheritance of open file descriptors in forked processes • I/O redirection from/to files, between processes • Shell uses file descriptor 0 for standard intput and 1 for output • How does protection work in Unix? • Through access control lists in the file system • Owner, group, everyone else • Set-User-ID for protection domain transfers

  3. Protection in Multics

  4. The Three Questions • What’s the problem? • What is new or different? • What are the contributions and limitations?

  5. Diggin’ Deeper • How to design for protection? • Design principles • How to specify access restrictions? • Access control lists • How to authenticate users? • Passwords • How to protect memory? • Segment descriptors • Where did we go wrong? • Size of trusted computing base, complexity of UI

  6. Design Principles • Five principles • Require explicit permission instead of exclusion • Check every access • Do not rely on security by obscurity • Operate with the least necessary privilege • Make the UI easy to use • Two functional objectives • Allow decentralized control • Make the protection system extensible • We cannot anticipate all ways of enforcing protection

  7. The Storage Systemand Access Control • A hierarchical storage system • Comprising catalogs (directories) and segments (files) • Later message queues and removable media descriptors • Accessed through memory-mapped I/O • Each storage system object has an ACL • Mapping from principals to access rights • Principals are partitioned into three parts • User name • Project • Compartment • ACL entries may contain wildcards for partitions

  8. More Details on Access Control • Access control lists are ordered • First match determines rights • Need to carefully insert new entries, favoring more specific ones • Each directory has a default ACL • Copied onto new objects • Users and projects never go away • Otherwise, would have to delete invalid ACL entries (?) • Object owner has full control over ACL • Others cannot restrict it (!?) • E.g., instructor cannot set overall policy for students

  9. Even More Details:Hierarchical Controls • Access control is hierarchical • Write access to directories implies right to modify ACLs • Can be used to provide centralized control • Detour: Access control in Windows 2000 • Swift et al., ACM TISSEC 5(4):398-437, Nov. 2002 • Supports both centralized and local control • Using inherited as well as local ACL entries • Favors speed of access checks over space used by ACLs • Policy propagated down the tree after ACL changes • Places local entries before inherited entries • First matching entry applies

  10. Some Rejected Design Points • Placing permissions on objects(instead of placing them on ACL entries) • Too inflexible as different users need different rights • CTSS put permissions on objects,used (hard) links as separate entry points (capabilities) • Hard to revoke access • Access modes to same object depend on name • Hard to determine rights • Using user-specified reference monitors • Hard to isolate the owner-specified procedure • Cannot run as user seeking access — why? • Cannot run as supervisor — why?

  11. User Authentication • Based on user names and passwords • All operations require (interactive) authentication • Supports proxy logins (!?) • Generates passwords automatically • With English digraph statistics • Stores passwords in encrypted form • Does not print passwords • Automatically logs out idle users • Tracks (un)successful logins • Supports stronger checks and anonymous logins

  12. Memory organized into segments Each memory access is through a segment descriptor Per-process descriptor segment lists all descriptors Pointer to physical memory List of access rights Number of gates ID of protected subsystem (0-7) Which modern processor also uses rings of protection? Can we think of a more flexible scheme?Or, do we need more flexibility? Memory Protection

  13. Memory Protection (cont.) • I/O channel programs (drivers) run as supervisor • Overall, memory protection allows for economy of mechanism • One mechanism to access data • One mechanism to control everyone • Including the supervisor

  14. Two Major Weaknesses • Size of trusted computing base • 15% of all code, 300 modules with ~200 lines (60,000 lines) • Three factors • Presumed execution speed • Tight deadlines • Lack of understanding • Complexity of user interface for access lists • Permitted users and projects • Corresponding permissions • Right to backup, perform bulk I/O • Protected subsystem

  15. More Weaknesses • Communication lines are weak • Operator interface is weak • Direct access to hardware • Users may specify their own passwords • No semantic checks on supervisor interface • Secondary storage is cleared on reuse not deallocation • Administrators are overprivileged • Backups expose other users’ directories

  16. More Weaknesses (cont.) • Counter-intelligence is lacking • Hardware protection may fail • “Relatively straight forward modification can easily strengthen any of the areas” • Do we believe this?

  17. Discussion

More Related