Bell-LaPadula, Biba and MLS
The two classic multilevel-security models: Bell-LaPadula for confidentiality and Biba for integrity, stated property by property so the two are never confused for each other.
- State the Bell-LaPadula simple security property and *-property by name and by direction.
- State the Biba simple integrity, *-integrity and invocation properties by name and by direction.
- Work a subject's read and write verdict under both models at the same clearance and classification.
- List the four criticisms the lecture makes of Bell-LaPadula, and where Biba variants actually appear in practice.
26 min readJump to the quiz ↓
Multilevel security has to reason about reads and writes together
A Top Secret file and a Secret file carry different consequences if the wrong person reads them. A single clearance check sounds like enough, but a subject both reads and writes, and those two directions leak information in different ways even when every individual read and write looks authorised.
Multilevel security (MLS) handles information at different classification levels inside one system: this unit’s examples use Top Secret, Secret, Confidential and Unclassified, from highest to lowest. Users hold a clearance at one of these levels; 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, whatever any ordinary user or even the administrator tries. It is harder to build than it sounds: the lecture’s example is how a system automatically reduces a document from Top Secret to Secret so Secret-cleared people can read it without a human making that judgement 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 once the incentives and threat model are understood. Bell-LaPadula and Biba are the two this unit develops.
Bell-LaPadula protects confidentiality: no read up, no write down
Bell-LaPadula (BLP) was proposed in 1973. In the 1970s it was recognised that operating systems would always contain vulnerabilities users could work around, so MLS needed mandatory access control that a user’s own actions could not bypass, however convincingly a program appeared to have permission. BLP defines two mandatory properties about the direction information may 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: a subject can read its own level or below, and write its own level or above.
The simple security property: no subject may read data at a higher level ("no read up"). The *-property: no subject may write data to a lower level ("no write down") — this is the one that matters, because it stops a low-clearance user from planting a program for a high-clearance user to run by accident, which would otherwise leak upward data downward. A subject cleared to Secret can read Confidential and below, and write to Top Secret and above, but the two blocked edges above are the entire point of the model: it protects confidentiality, and only confidentiality.
The *-property blocks a classic leak. A user cleared to a low level cannot read high-level data, so writes a program at their own level and waits for a higher-cleared user to run it by accident. If that process could write the data back down to where the low user can reach it, the secret would leak with nobody reading above their clearance. No write down applies to every process, however it was tricked into running, so the attempt fails at the write.
BLP also carries one discretionary component: an external entity can define, in a matrix, exactly which operations a subject holds over an object, narrowing what is allowed inside the boundary the two mandatory properties set.
Exam detail
BLP draws four criticisms in the lecture, each worth naming on its own.
- Single trusted principal. The whole model is administered by one omnipotent Trusted Principal, which pushes the question of security onto securing that one central authority.
- Confidentiality only. BLP does not address integrity at all. A subject cleared to Unclassified can still write up to a Top Secret object under the *-property, even though it cannot read it, which is enough to corrupt the object without seeing its contents.
- Covert channels. BLP has no answer for a channel nobody designed for communication being used for it. The lecture’s example: a high-level process encodes a bit as high or low CPU load, and a low-level process estimates the load to read the bit back, without either performing a write the *-property would catch. A side channel differs: an attacker passively infers information from an artefact of normal operation, such as packet timing or a heat signature, with no deliberate encoding at the source.
- Non-composability. Combining two systems that are each BLP-secure does not guarantee the combined system is.
Biba reverses the directions to protect integrity
Biba addresses integrity instead of confidentiality: not who can see data, but whether it can be trusted not to have been tampered with. Its three properties reverse 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 govern direct reads and writes. The invocation property governs which processes a process can call or request a service from, stopping a low-integrity process from getting a trusted, higher-integrity one to act on its behalf: the integrity equivalent of the confused deputy problem.
Biba protects integrity, not confidentiality, and is Bell-LaPadula reversed: the simple integrity property is "no read down", the *-integrity property is "no write up". Compare the two blocked edges against the Bell-LaPadula diagram above — same layout, opposite result. A low-integrity process reading high-integrity data would trust something it cannot verify; a low-integrity process writing to high-integrity data would corrupt something trusted. Both are blocked for the same reason confidentiality-writes-down are blocked in Bell-LaPadula: to stop contamination flowing the wrong way.
Two lecture examples make the direction concrete. An aircraft’s in-flight entertainment system can read avionics data, airspeed among it, but cannot write to any of it, so a bug in the entertainment system cannot touch flight controls. A car’s odometer can display the recorded mileage but cannot alter it. Both are the *-integrity property doing its job.
Pure implementations of either model are rare, because real systems have security needs too varied for one formal model. Variants of Biba are more common than pure Bell-LaPadula, because users accept being stopped from corrupting trusted data more readily than being told what they cannot read. The lecture names Windows Vista, SELinux, some versions of Red Hat, and a FreeBSD module as places Biba-style variants appear.
The two models give opposite verdicts on the same pair of levels
Compare
Bell-LaPadula
Protects confidentiality. Simple security property: no read up. *-property: no write down. A subject can read its own level or below, and write its own level or above.
Biba
Protects integrity. Simple integrity property: no read down. *-integrity property: no write up. A subject can read its own level or above, and write its own level or below.
Pitfall
The most common way to lose marks here is naming the right direction but the wrong model, or the right model but the wrong direction. “No write down” belongs to Bell-LaPadula. “No write up” belongs to Biba. They are opposite rules that share the same shape. When a question asks about Biba, answer with Biba’s own property names, not Bell-LaPadula’s with the direction flipped in your head.
Try it — worked example
A subject cleared to Secret wants to read and to write an object classified Top Secret. What does Bell-LaPadula allow? What does Biba allow?
Show answer and steps
AnswerSubject cleared to Secret, object classified Top Secret: BLP denies the read and allows the write; Biba allows the read and denies the write.
Take the four MLS levels in order, Unclassified below Confidential below Secret below Top Secret, and a subject cleared to Secret trying to read from, and write to, an object classified Top Secret, one level above.
Bell-LaPadula read. The object is above the subject’s clearance, so this is reading up. The simple security property forbids it. Denied.
Bell-LaPadula write. This is writing up. The *-property only forbids writing down. Allowed.
Biba read. Reading up is what the simple integrity property allows, since a subject may read its own level or higher. Allowed.
Biba write. Writing up is exactly what the *-integrity property forbids. Denied.
Every verdict flips between the models on the same pair of levels. That reversal is the entire content of “Biba is the dual of Bell-LaPadula.”
The lecture frames the same flip with named people: a user cleared to Low wants codes locked at Medium. Under Bell-LaPadula they cannot read the codes (reading up is blocked), and a higher-cleared user cannot fetch them either, because that user cannot write them back down to Low. Under Biba the Low user reads up directly, and the higher user can write down to change any of the codes. Only the model changed, not the levels.
Recall
Same subject clearance, same object classification: why can a write be allowed under Bell-LaPadula and denied under Biba at the very same two levels?
Because the two models enforce opposite directions. Bell-LaPadula’s *-property blocks writing down, so writing up or level is fine. Biba’s *-integrity property blocks writing up, so the identical write that Bell-LaPadula allowed is exactly the one Biba forbids.
Check yourself
Source
Week 3 slides PDF