Editor's preface to the Bell-LaPadula model

Jonathan Millen
1996 Journal of Computer Security  
229 This issue includes volume 11 of the Bell-LaPadula model. The Bell-LaPadula model played, and continues to play, an important role in the development of multilevel computer security. It was called for as part of the DaD paradigm for implementing secure systems, as described in an Air Force planning study [1]. The Anderson Report recommended using a model of an "ideal system" as the starting point for the design, and David Bell and Leonard LaPadula of The MITRE Corporation were commissioned
more » ... o write one. Between them, Bell and LaPadula generated several versions of the model. Volumes I-Ill contained different, progressively more complex models. The later models reflected different design decisions; they were not refinements of earlier ones. There was also a "Unified Exposition and Multics Interpretation". Volume I [2] took its inspiration from general systems theory rather than the theory of automata, though it adopted the access matrix idea from contemporary operating system design papers. It modelled a system as having subjects, objects, and a current state with three components: an access relation, indicating the existence of current access to an object by a subject; an access matrix, indicating the types of access (read, write, copy, append, owner, or control); and an assignment of classifications and need-to-know categories to subjects and objects. State transitions involved requests and decisions, which were not listed. In a secure state, any kind of access by a subject to an object required that the subject dominate the object in classification and need-to-know categories. Volume 11 [3] limited the access types to read, write, append, execute, and control. It introduced a form of the *-property, with execute access viewed as a kind of read, and "write" access implying both read and write; append access was write-only. It had ten specific transition rules. The access relation now indicated the access types, and the access matrix became a permission matrix for discretionary access control. Rules for giving and rescinding discretionary access permissions tested control access. Volume III [4] introduced an object hierarchy as a new component of the state, doing away with control access. A subject had the equivalent of control access, the ability to change an object's security attributes, if it had write access to the parent object. Subjects were given a "current" security level, distinct from, but dominated by their maximum security level, leading to a change in the way the *-property was stated. The Multics Interpretation [5] revised the rules to be a better match for the Multics kernel primitives,. and it added the discretionary security property as an axiom, which stated explicitly that current access must be consistent with the permission matrix.
doi:10.3233/jcs-1996-42-306 fatcat:xxcf6gwwufe3dkzvepejg2ypcq