Multilevel security (MLS) is a technology to protect secrets from leaking between computer users, when some are allowed to see those secrets and others are not. This is generally used in defense applications (the military and intelligence communities) since nobody else is nearly as paranoid about data leaking. A modern wrinkle on this is called cross domain systems (CDS) in which we speak of domains instead of levels, and are usually sharing data on computer networks instead of individual computers

Personally, I was introduced to MLS through my work on the LOCK trusted computing system in the early 1990s.

Here are some MLS materials available on this site:

• A general introduction to MLS
• A commentary about MLS based on meetings with defense security experts in the late 1990s, when we tried to map a new way forward.
• An e-mail about MLS and Internet server protection written for the old Firewalls mailing list in the 1990s.
• MLS versus Type Enforcement versus chroot() A paper (PDF) comparing the use of MLS and Type Enforcement and Unix chroot() for protecting Internet servers. The paper was based on an e-mail discussion from the old “Firewalls” mailing list. The e-mail noted above was part of that discussion.
• Building a high assurance system A paper (PDF) on the cost of building a high assurance MLS system.
• The Standard Mail Guard A paper (PDF) on an almost off-the-shelf MLS product.

Note that some people like to spell it “multi-level security.” I think the term is old enough that we can omit the hyphen.

Ambiguous terminology

Several years ago I was at a workshop sponsored by the Air Force to develop some new directions for information systems improvements. The workshop included both “end user” representatives from the Air Force and “R&D” representatives from laboratories and government contractors.

Discussions on MLS capabilities became rather heated. One vendor representative from the security working group declared the following in a plenary session:

“Don’t ask for MLS. We’ve tried to give you MLS, but in fact you’ve never really wanted it or used it. But please, tell us what you do want!”

A voice in the back shouted, “MLS!”

That little incident reflects an important fact about MLS: it’s 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. In her well-known paper on software safety, Nancy Leveson criticizes this type of labeling:

Labeling a technique, e.g., “software diversity” or “expert system,” with the property we hope to achieve by it (and need to prove about it) is misleading and unscientific.

Unfortunately, we’re stuck with the established terminology, so now we must focus on distinguishing between the two meanings.

 

 

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