Philosophical Aspects, Ease of Use, Flexibility
It is interesting to consider the philosophical implications of the MSL "solution path." Rather than providing MLS abilities within a classical OS, the chosen direction is to build a set of "virtual OS" peers that can be managed, individually and as a collective, by an underlying real OS. If the underlying OS (let us introduce the term maintenance operating system, or MOS) is to have sufficient understanding of MLS semantics to prevent grievous errors, such as copying data from a TOP SECRET MSL peer to an UNCLASSIFIED MSL peer, then the MOS must have the ability to: represent labels; associate labels with entities (here we rigorously avoid the terms "subject" and "object"); compare labels (rigorously avoiding the term "reference monitor"); distinguish between those contexts where labels are meaningful and those where they are not (rigorously avoiding the term "trusted computing base" ); the list goes on. One readily perceives that the MLS architecture and design issues have not been eliminated, merely deferred to a separate stratum of software that invisibly manages mandatory access control concerns so that superjacent strata need not. This concept is none other than the geminal architectural concept (taken from the Anderson Report) underlying DoD-style trusted systems in the first place.
What has been positively achieved by the set-of-MSL-peers abstraction, albeit, is radical restriction of the scope of MAC-cognizant software mechanisms to the small, subjacent MOS. This has been accomplished, however, at the cost of eliminating any practical MLS abilities, even the most elementary ones, as when a SECRET-cleared user appends an UNCLASSIFIED paragraph, taken from an UNCLASSIFIED file, to his SECRET report. The MSL implementation would obviously require every "reusable" resource (in this example, the UNCLASSIFIED file) to be replicated across every MSL peer that might find it useful—meaning either much secondary storage needlessly expended or intolerable burden on the cleared administrator able to effect such replications in response to users' requests therefor. (Of course, since the SECRET user cannot "browse" the system's UNCLASSIFIED offerings other than by logging out and beginning an UNCLASSIFIED system afresh, one evidences yet another severe limitation on functionality and flexibility.) Alternatively, less sensitive file systems could be NFS-mounted read-only so that more trustworthy users could browse, but not modify, their content. Albeit, the MLS OS peer would have no actual means for distinguishing (via a directory listing command, e.g.) that the NFS-mounted resources are at a different level of sensitivity than the local resources, and no strict means for preventing illegal uphill flow of sensitive information other than the brute-force, all-or-nothing mechanism of read-only NFS mounting.
To demonstrate just what a handicap this drastic effectuation of "cross-level file sharing" actually is, consider the case of an MLS system that supports UNCLASSIFIED, SECRET, and TOP SECRET data, and a TOP SECRET cleared user who logs in to the system at that level. MLS directory structures are built around the containment principle, which, loosely speaking, dictates that higher sensitivity levels reside deeper in the tree: commonly, the level of a directory must match or dominate that of its parent, while the level of a file (more specifically, of any link thereto) must match that of the directory that catalogs it. (This is strictly true of MLS UNIX: alternatives that support different conceptions of directories, directory entries, i-nodes, etc.—such as Multics, which adds the "branch" abstraction to its directory paradigm—tolerate a broader set of alternative implementations.) Orthogonal mechanisms are provided for publicly shared and spool directories, such as /tmp or C:\TEMP, which are automatically—and invisibly—partitioned by the OS, with users' file access requests automatically "deflected" to the appropriately labeled directory partition. The TOP SECRET user is free to browse the entire system, his only restriction being that—while logged in at that level—he is only allowed to create fresh TOP SECRET files within specific directories or their descendants. In the MSL alternative, where any browsable content must be specifically, laboriously replicated across all applicable levels by a fully cleared administrator—meaning, in this case, that all SECRET data must be replicated to the TOP SECRET MSL peer OS, while all UNCLASSIFIED data must be replicated to both the SECRET and TOP SECRET peers—one can readily perceive that, the more highly cleared the user, the more frustrating his timesharing computing experience will be.
In a classical trusted systems-theoretic sense—relying upon terminology and concepts taken from the Orange Book, the foundation of trusted computing—a system that supports MSL peers could not achieve a level of assurance beyond (B1). This is because the (B2) criteria require, among other things, both clear identification of a TCB perimeter and the existence of a single, identifiable entity that has the ability and authority to adjudicate access to all data represented throughout all accessible resources of the ADP system. In a very real sense, then, the application of the term "high assurance" as a descriptor of MSL implementations is nonsensical, since the term "high assurance" is properly limited to (B3) and (A1) systems—and, with some laxity albeit, to (B2) systems.
Read more about this topic: Multiple Single-level