Multilevel security (MLS) is an overloaded term that describes both an abstract security objective and a well-known mechanism that is supposed to achieve that objective, more or less.

Click here for a general introduction to MLS.

MLS: The Objective

A system or device achieves the objective of being “multilevel secure” if it can handle information at a variety of sensitivity levels without disclosing information to an unauthorized person. In a perfect world, this yields two more specific objectives:

• If a document contains classified information, then the system will prevent the document from being delivered to a user who lacks the appropriate clearance. For example, a document containing Top Secret information can’t be given to a user who only has a Secret clearance. This is the information flow problem.
• If a document contains no information above a particular classification level, then it can be shared with users who have that clearance. For example, if a Top Secret user takes a Top Secret document and removes all information classified above the Secret level, then the system should allow Secret users to look at the document. This is the sanitization problem.

The information flow problem is very hard to solve through automated access restrictions. The sanitization problem is almost impossible to solve through automated access restrictions.

A device enforces MLS information flow if it can’t be induced (accidentally or intentionally) to release information to the wrong person. The U.S. government has a body of laws and regulations that make it illegal to share classified information with people who do not possess the appropriate security clearance. In theory, an “MLS device” will automatically enforce those restrictions. Some defense officials refer to MLS devices as felony boxes since they can automatically commit felonies if they malfunction.

While it might seem easy to implement such a thing just by setting up the right access restrictions on files, this approach isn’t reliable enough for large-scale use. For one thing, it’s hard to reliably establish and review the permission settings for hundreds or even thousands of files and expect to have them all set correctly at all times. Another problem is that a malicious user could leak enormous amounts of classified information with a few simple keystrokes. Moreover, an innocent user could be tricked into releasing comparable amounts of classified information if subjected to a virus or other malicious software.

The sanitization problem is made difficult by two things. First, it assumes that software applications don’t hide data from their users, and that simply isn’t true. A Microsoft Word file carries all sorts of information, including reams of text that its owner may have tried to remove. There are even circumstances where cut-and-paste may copy deleted information from one Word file to another. The second problem is that it requires a certain level of intellect to distinguish more-sensitive informaiton from less-sensitive information. While classifying authorities may sometimes attempt to make it obvious which data is Top Secret, which is Secret, and which is unclassified, it is often impossible in practice to build an automated tool to identify sensitivity simply on the basis of the unmarked material.

MLS: The Mechanism

In practice, the devices we generally recognize as implementing “MLS” are based on a hierarchical, lattice-based access control model developed for the Multics operating system in 1975. In this model, the system assigns security classification labels to processes it runs and to files and other system-level objects, particularly those containing data. The mechanism enforces the following rules:

• A process is always allowed to read and write an object if the process’ label matches the object’s label (subject to other permissions, like those linked to file ownership).
• A process is allowed to read the data in an object if the object’s classification label is lower than the process’ label. For example, a “secret” process can read data from an “unclassified” object, but never vice versa.
• A process is never allowed to write data to an object when the object’s classification label is lower than the process’ label. This prevents programs from accidentally leaking classified information into files where unauthorized users might see the data. More importantly, it prevents users from being tricked into leaking information by trojan horse programs.

The mechanism is also referred to as mandatory access control because it is always enforced and users could not disable or bypass it. One of the reasons why you can’t reliably enforce MLS (the objective) with conventional access control mechanisms is that such mechanisms are usually under the complete control of a file’s owner. Thus the owner can accidentally or intentionally violate the access control rules simply by changing the permissions on a sensitive file. The MLS mechanism is mandatory, which means that individual users can’t really control it themselves. Once a file is labeled “top secret,” the MLS mechanism won’t permit the user to share it with merely “secret” users or to mingle its contents with that of “secret” files. Once “top secret” information is mixed with “secret” information, the aggregate becomes “top secret.”

The original motivation for building MLS mechanisms was the perception that it would make applications development safe from serious security risks. The notion was that applications programmers would be saved from the bother of having to worry about security labels. Existing applications would be able to handle labeled data safely and correctly without reprogramming. Even more important, programmers would not be able to sneak data between security levels by writing clever programs: the MLS protection mechanism would prevent any attempt to violate the most important security constraints on the system.

MLS: Hard to Implement

Although this basic MLS mechanism may seem simple to implement, it proved very difficult to implement effectively. Several systems were developed that enforced the security rules, but experimenters quickly found ways to bypass the mechanism and leak data from high classification levels to low ones. The techniques were often called covert channels. These channels used operating system resources to transmit data between higher classified processes and lower classified processes. For example, the higher process might systematically modify a file name or other file system resource (like the free space count for the disk or for main memory) that is visible to the lower process in order to transmit data.

Attempts to block covert channels led to very expensive operating system development efforts. The resulting systems were hard to use in practice and often had performance problems. While it’s never been conclusively proven that you can’t build a high performance system that avoids or blocks covert channels, there are no working examples.

The high cost of MLS systems was also driven by the high cost of security product evaluations performed by the US government.

MLS: An Impractical Mechanism

Although MLS (the objective) remains a requirement for many military and government systems, the objective is not met by MLS (the mechanism). The fundamental problem is that the mechanism only allows data to flow “upwards” in terms of sensitivity. So, automatic software can easily take unclassified data, mix it with secret data to make more secret data, and then with top secret data to produce more top secret data. There are a few applications in the intelligence community where this is a very useful property.

However, this upward flow works against modern notions of “information dominance” and “sensor to shooter” information flow. The modern concept is that technical intelligence assets should identify targets, pass the information to mission planners, who assemble a mission, and pass the mission details to tactical assets, who in turn share details with support and maintenance assets. The problem is that technical intelligence, mission planning, tactical assets, and support assets tend to operate at decreasing security levels. The flow of information goes the exact opposite of what the MLS mechanism allows.

 

This article by Rick Smith is licensed under a Creative Commons Attribution 3.0 United States License.