An Overview of Multilevel Security and LSPP under Linux

MLS Background
I was planning on writing an introductory article on Multilevel Security (MLS), to be published here or at another online venue. The purpose being to provide a gentle introduction to the subject for those wishing to understand MLS under SELinux.

During my research, I came across a good introductory article online by Dr Rick Smith: Introduction to Multilevel Security.

Rather than covering much of the same ground, but not as well, I’d instead recommend that people who are interested in getting started learning about MLS simply go and read that (at least the Introduction section).

Other online materials worth tracking down are manuals for “trusted” versions of a couple of remaining Unix variants (e.g. Trusted Solaris), keeping in mind that implementation details will vary.

Book-wise, I’d recommend:

  • Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson (a general, indispensable security book with some coverage of MLS)
  • Fundamentals of Computer Security Technology by Edward Amoroso (essential text covering many of the MLS concepts and technologies in more detail).

Brief Concepts and Terms
However, I will very briefly outline a few key concepts, and terms as we use them. (MLS terminology is a confusing mess across different implementations and standards).

MLS, as discussed here, refers to a specific Mandatory Access Control (MAC) security scheme. Under this scheme, processes are called Subjects. Files, sockets and other passive operating system entities are called Objects.

Subjects and Objects are labeled with Security Levels (SLs).

An SL is composed of two types of entities:

  1. Sensitivity: An hierarchical attribute such as “Secret” or “Top Secret”
  2. Categories: A set of non hierarchical attributes such as “US Only” or “UFO”

An SL must have one sensitivity, and may have zero or more categories.

Examples of SLs are: { Secret / UFO, Crypto }, { Top Secret / UFO, Crypto, Stargate } and { Unclassified }

Note the hierarchical sensitivity followed by zero or more categories. The reason why we have categories as well as sensitivities is so that sensitivities can be further compartmented on a need to know basis. For example, while a user may be cleared to Secret, they may not need to know anything about project WarpDrive (which could be the name of a category).

– SLs on Objects are called classifications.
– SLs on Subjects are called clearances.

Thus, Objects are labeled with a classification while Subjects operate with a specific clearance. SLs can have also ranges, but we’ll keep it simple here and ignore that.

MLS Policy
The rules governing MLS access are quite complicated (sometimes counter-intuitive), and covered in detail in some of the references listed above. There are several MLS models. The most common, Bell-LaPadula (BLP) deals with confidentiality. Another, Biba, provides an integrity model. Some existing systems use both. SELinux actually uses BLP, with Type Enforcement (TE) for integrity.

But in very simple terms, MLS policy will ensure that a Subject has an appropriate clearance to access an Object of a particular classification.

For example, under MLS, the system will need to know how to answer a question like:

Can a process running with a clearance of { Top Secret / UFO, Railgun } write to a file classified as { Top Secret / UFO } ?

The MLS model and policy implemented for it will determine the answer. (As an exercise, consider the problem of information leaking out of the Railgun category into the file).

MLS meets a very narrow (yet critical) set of security requirements based around the way information and personnel are managed in rigidly controlled environments such as the military. To my knowledge, MLS has not been widely successful in the general commercial world, although there are apparently a few commercial MLS deployments. MLS is typically very difficult to work with and maps very poorly to general case scenarios.

Type Enforcement under SELinux is actually a far more flexible and expressive security scheme, which is in many cases more suitable than MLS, although there are several scenarios where traditional MLS is still required. For example, when you have a large number of Security Levels and a need for strong isolation on a single system; such as a file server where the stored data may be of mixed classification and where clients connect at different clearances. This type of scenario is the reason that SELinux includes MLS as a security model, as an adjunct to TE.

LSPP Certification
Currently, efforts are just underway to have Linux certified as an MLS operating system. The certification is equivalent to the old B1 rating, which has been reworked into the Labeled Security Protection Profile under the Common Criteria scheme.

People interested in participating in or following the LSPP effort should subscribe to the redhat-lspp mailing list via:

One of the issues with MLS is that it’s a very specialized security scheme with a narrow userbase. So, it’s really not a great fit with the open source development model. An important challenge we face is to engage the wider community with this technology by making it more generally useful. We (various SELinux developers) are currently working on an project which will attempt to do this, and we should hopefully have more to say on this soon. Currently it’s a matter of getting the initial work done and then integrated into Fedora.