Bell-LaPadula, Biba and MLS

Multilevel security (MLS) handles information at different classification levels inside one system: this unit’s own examples use Top Secret, Secret, Confidential and Unclassified, from highest to lowest. Users hold a clearance at one of these levels; documents and objects hold a classification at one of the same levels. MLS matters most in military and government settings, where a Top Secret file must never reach someone cleared only to Secret, no matter what any ordinary user, or even the administrator, tries to do.

MLS is harder to build well than it sounds. The lecture’s own example of the difficulty: how does a system automatically reduce a document’s classification from Top Secret to Secret, so that people cleared only to Secret can read it, without a human making that judgement call every time? There is no clean automated answer.

A security policy model is a precise, often formal, statement of a system’s protection properties, written after the incentives and threat model are understood and the policy itself is set down. Bell-LaPadula and Biba are the two this unit develops in full.

Bell-LaPadula (BLP) was proposed in 1973. Its motivation was the growing 1970s recognition that operating systems would always contain vulnerabilities users could work around, so multilevel security needed mandatory access control that a user’s own actions could not bypass, no matter how convincingly a program appeared to have permission.

BLP defines two mandatory properties, both about the direction information is allowed to flow:

• The simple security property, also called no read up: no subject may read data at a higher level than its own clearance.
• The *-property (star-property), also called no write down: no subject may write data to a lower level than its own clearance.

Restated the other way round: a subject can read its own level or below, and can write its own level or above.

BLP also carries one discretionary component alongside its two mandatory ones: an external entity can define, in a matrix, exactly which operations a given subject holds over a given object, on top of the level restrictions the mandatory properties already enforce. The lecture’s own matrix gives one user read and append rights on one object and read rights on another, while a second user gets read-write and append on the first and execute on the second. The mandatory properties set the outer boundary; the discretionary matrix narrows what is allowed inside it.

Biba addresses integrity instead of confidentiality: not who can see data, but whether it can be trusted not to have been tampered with. Its wording was checked directly against Biba’s own 1977 technical report, and its three properties are the reverse of Bell-LaPadula’s directions:

• The simple integrity property, also called no read down: a subject may only read data at its own level or higher.
• The *-integrity property, also called no write up: a subject may only write data at its own level or lower.
• The invocation property: a process cannot invoke another process at a higher integrity level, only at its own level or below.

The first two properties govern direct reads and writes of data. The invocation property is different in kind: it governs which processes a process can call or request a service from, stopping a low-integrity process getting a trusted, higher-integrity process to act on its behalf, the integrity equivalent of the confused deputy problem covered earlier in this module.

Two examples the lecture gives make the direction concrete. An aircraft’s in-flight entertainment system can read data from the avionics, airspeed among it, but cannot write to any of it: a bug in the entertainment system stays a bug in the entertainment system, and cannot touch flight controls. A car’s odometer can display the recorded mileage but cannot alter it: read up is fine, write up is not, and both examples are the *-integrity property doing its job.

The lecture frames a related scenario the same way with named people rather than classification labels: a user cleared to Low wants codes locked at Medium classification. Under Bell-LaPadula they cannot read the codes themselves, reading up is blocked, and asking a second user, cleared above Medium, to fetch them does not work either, because that second user cannot write the codes back down to the first user’s level. Under Biba the same request succeeds both ways: the Low-cleared user can read up to Medium directly, and the higher user can write down to change any of the codes they like. Nothing about the levels changed between the two versions of the story; only which model is being asked.

Pure implementations of either model, on their own, are rare: real systems have security needs too varied for one formal model to capture cleanly. Variants of Biba specifically are more common in practice than pure Bell-LaPadula, because integrity is easier to justify to users who dislike being told what they cannot read but accept being stopped from corrupting trusted data. The lecture names Windows Vista, SELinux, some versions of Red Hat, and a FreeBSD module as places Biba-style variants actually appear. The formal models still matter for discussing and designing real-world access control, even where no system implements either one exactly.