The paper describes the security concepts and the design of the security system in Multics. The goal is to provide:
The paper opens by listing and explaining the design principles that drove the Multics project. They are the following: (1) default situation is lack of access (i.e. protection is based on permission); (2) every access is checked; (3) design is not secret; (4) the principle of least privilege (a.k.a. need-to-know basis); (5) ease of use. Furthermore, the paper emphasizes the importance of decentralization of the setting of protection specifications, which means that users and supervisors alike can set permissions in they respective protected subsystems. A protected subsystem is a collection of programs and data such that the data may be accessed only by programs in the subsystem, and programs may be entered only at designed entry points. A generic organized storage system is the basis of information storage in Multics. The access control mechanism mediates access to this storage system, thus handling all the necessary protection responsibility. The access control list associates a principal with a list of permissions. A principal in the system is identified by 3 components: (a) user id; (b) project id (a.k.a. group id); and (c) compartment id (a.k.a. role id). User authentication is done through password, generated from English digraphs. In the hierarchical file structure, new directories and files receive the initial access control list from the parent directory, through access control list inheritance. Memory protection uses segments as the unit of protection, corresponding to data storage segments. The private descriptor segment is associated with the logical address not physical address, so different principals can have different levels of access to the same physical page. The association of access control data is different from storage system ACLs, where the access control data is located with the physical segment. |