Data Security and Privacy
Topic 5: The Bell LaPadula Model
1
Announcements
• Quiz on Thursday Jan 25
2
Readings for This Lecture
• Wikipedia
• Bell-LaPadula model
• David E. Bell: Looking Back at the
Bell-La Padula Model
3
Access Control at Different
Abstractions
• Using principals
– Determines which principals (user accounts) can
access what documents
• Using subjects
– Determines which subjects (processes) can access
what resources
– This is where BLP focuses on
4
Multi-Level Security (MLS)
• There are security classifications or security levels
– Users/principals/subjects have security clearances
– Objects have security classifications
• Example of security levels
– Top Secret
– Secret
– Confidential
– Unclassified
• In this case Top Secret > Secret > Confidential >
Unclassified
• Security goal (confidentiality): ensures that information do
not flow to those not cleared for that level
5
Multi-level Security (MLS)
• The capability of a computer system to carry
information with different sensitivities (i.e.
classified information at different security levels),
permit simultaneous access by users with
different security clearances and needs-to-know,
and prevent users from obtaining access to
information for which they lack authorization.
– Discretionary access control fails to achieve MLS
• Typically use Mandatory Access Control
• Primary Security Goal: Confidentiality
6
Mandatory Access Control
• Mandatory access controls (MAC) restrict
the access of subjects to objects based on
a system-wide policy
– denying users full control over the access to
resources that they create. The system
security policy (as set by the administrator)
entirely determines the access rights granted
7
Bell-LaPadula Model: A MAC Model
for Achieving Multi-level Security
• Introduce in 1973
• Air Force was concerned with security in time-
sharing systems
– Many OS bugs
– Accidental misuse
• Main Objective:
– Enable one to formally show that a computer system
can securely process classified information
8
What is a Security Model?
• A model describes the system
– e.g., a high level specification or an abstract machine
description of what the system does
• A security policy
– defines the security requirements for a given system
• Verification techniques that can be used to show
that a policy is satisfied by a system
• System Model + Security Policy = Security Model
9
Approach of BLP
• Use state-transition systems to describe
computer systems
• Define a system as secure iff. every reachable
state satisfies 3 properties
– simple-security property, *-property, discretionary-
security property
• Prove a Basic Security Theorem (BST)
– so that give the description of a system, one can prove
that the system is secure
10
The BLP Security Model
• A computer system is modeled as a state-
transition system
– There is a set of subjects; some are designated as
trusted.
– Each state has objects, an access matrix, and the
current access information.
– There are state transition rules describing how a
system can go from one state to another
– Each subject s has a maximal sec level Lm(s), and a
current sec level Lc(s)
– Each object has a classification level
11
Elements of the BLP Model
Security levels, e.g.: {TS, S, C, U}
Lm: Max Lc: Current L: Class.
Sec. Level Sec. Level Level
Subjects Objects
Current
Accesses
Trusted
Subjects
Access Matrix
12
The BLP Security Policy
• A state is secure if it satisfies
– Simple Security Condition (no read up):
• S can read O iff Lm(S) ≥ L(O)
– The Star Property (no write down): for any S that is not
trusted
• S can read O iff Lc(S) ≥ L(O) (no read up)
• S can write O iff Lc(S) ≤ L(O) (no write down)
– Discretionary-security property
• every access is allowed by the access matrix
• A system is secure if and only if every reachable
state is secure.
13
Implication of the BLP Policy
Objects
Highest
Can Write
Subject Max Level
Current
Can Read & Write
Level
Can Read
Lowest
14
STAR-PROPERTY
• Applies to subjects not to principals and users
• Users are trusted (must be trusted) not to
disclose secret information outside of the
computer system
• Subjects are not trusted because they may
have Trojan Horses embedded in the code they
execute
• Star-property prevents overt leakage of
information and does not address the covert
channel problem
15
Is BLP Notion of Security Good?
• The objective of BLP security is to ensure
– a subject cleared at a low level should never read
information classified high
• The ss-property and the *-property are sufficient
to stop such information flow at any given state.
• What about information flow across states?
16
BLP Security Is Not Sufficient!
• Consider a system with s1,s2,o1,o2
– fS(s1)=fC(s1)=fO(o1)=high
– fS(s2)=fC(s2)=fO(o2) =low
• And the following execution
– s1 gets access to o1, read something, release access,
then change current level to low, get write access to
o2, write to o2
• Every state is secure, yet illegal information
exists
• Solution: tranquility principle: subject cannot
change current levels, or cannot drop to below
the highest level read so far
17
More on the BLP Notion of Security
• When a subject A copies information from high to a low
object f, this violates the star-property, but no information
leakage occurred yet
– Only when B, who is not cleared at high, reads f, does leakage
occurs
– If the access matrix limits access to f only to A, then such leakage
may never occur
• BLP notion of security is neither sufficient nor necessary
to stop illegal information flow (through direct/overt
channels)
• The state based approach is too low level and
limited in expressive power
18
How to Fix The BLP Notion of
Security?
• May need to differentiate externally visible
objects from other objects
– e.g., a printer is different from a memory object
• State-sequence based property
– e.g., exists no sequence of states so that there is an
information path from a high object to a low externally
visible object or to a low subject
19
The Basic Security Theorem
• This provides the verification techniques piece in
– Model – Policy – Verification framework
• Restatement of The Basic Security Theorem: A
system is a secure system if and only if the
starting state is a secure state and each action
(concrete state transition that could occur in an
execution sequence) of the system leads the
system into a secure state.
20
Observations of the BST
• The BST is purely a result of defining security as
a state-based property.
– It holds for any other state-based property
• The BST cannot be used to justify that the BLP
notion of security is “good”
– This is McLean’s main point in his papers
• “A Comment on the Basic Security Theorem of Bell and
LaPadula” [1985]
• “Reasoning About Security Models” [1987]
• “The Specification and Modeling of Computer Security”
[1990]
21
Main Contributions of BLP
• The overall methodology to show that a system
is secure
– adopted in many later works
• The state-transition model
– which includes an access matrix, subject security
levels, object levels, etc.
• The introduction of *-property
– ss-property is not enough to stop illegal information
flow
22
Other Limitations with BLP
• Deal only with confidentiality, does not deal with
integrity at all
– Confidentiality is often not as important as integrity in
most situations
– Addressed by integrity models (such as Biba, Clark-
Wilson, which we will cover later)
• Does not deal with information flow through
covert channels
23
Overt (Explicit) Channels vs. Covert
Channels
• Security objective of MLS in general, BLP in
particular is
– high-classified information cannot flow to low-cleared
users
• Illegal information flow via overt channels (e.g.,
read/write an object) is blocked by BLP
• Illegal information flow by covert channels can
still occur
– communication channel based on the use of system
resources not normally intended for communication
between the subjects (processes) in the system
24
Examples of Covert Channels
• Using file lock as a shared boolean variable
• By varying its ratio of computing to input/output
or its paging rate, the service can transmit
information to a concurrently running process
• Timing of packets being sent
• Covert channels are often noisy
• However, information theory and coding theory
can be used to encode and decode information
through noisy channels
25
More on Covert Channels
• Covert channels cannot be blocked by *-property
• It is generally very difficult, if not impossible, to
block all covert channels
• One can try to limit the bandwidth of covert
channels
• Military requires cryptographic components be
implemented in hardware
– to avoid trojan horse leaking keys through covert
channels
• Covert channels are achieved by collaboration or
high and low subjects.
26
More on MLS: Security Levels
• Used as attributes of both subjects & objects
– clearance & classification
• Typical military security levels:
– top secret secret confidential unclassified
• Typical commercial security levels
– restricted proprietary sensitive public
27
Security Categories
• Also known as compartments
• Typical military security categories
– army, navy, air force
– nato, nasa, noforn
• Typical commercial security categories
– Sales, R&D, HR
– Dept A, Dept B, Dept C
28
Security Labels
• Labels = Levels P (Categories)
• Define an ordering relationship among Labels
– (e1, C1) (e2, C2) iff. e1 e2 and C1 C2
• This ordering relation is a partial order
– reflexive, transitive, anti-symmetric
– e.g.,
• All security labels form a lattice
29
An Example Security Lattice
• levels={top secret, secret}
• categories={army,navy}
Top Secret, {army, navy}
Top Secret, Top Secret, Secret, {army,
{army} {navy} navy}
Top Secret, {} Secret, {army} Secret, {navy}
Secret, {}
30
The need-to-know principle
• Even if someone has all the necessary official
approvals (such as a security clearance) to
access certain information they should not be
given access to such information unless they
have a need to know: that is, unless access to
the specific information necessary for the
conduct of one's official duties.
• Can be implemented using categories and or
DAC
31
Terminology: Trusted Computing Base
(TCB)
• The set of all hardware, software and procedural
components that enforcing the security policy depends
upon.
– In order to break security, an attacker must subvert some part of
the TCB.
– The smaller the TCB, the more secure a system is.
• What consists of the conceptual Trusted Computing
Based in a Unix/Linux system?
– Depends on the security objective
– hardware, kernel, system binaries, system configuration files,
setuid root programs, etc., at the minimum
One approach to improve security is to reduce the size of
TCB, i.e., reduce what one relies on for security.
32
Assurance
• Assurance: “estimate of the likelihood that a
system will not fail in some particular way”
• Based on factors such as
– Software architecture
• E.g., kernelized design,
– Development process
– Who developed it
– Technical assessment
33
Kernelized Design for High-
Assurance Systems
• Uses the reference monitor User space
concept
User
process
• Reference monitor
– Part of TCB
– All system calls go through
reference monitor for security
Reference
checking monitor
– Security does not depends on TCB
the whole kernel
– Most OS not designed this way OS kernel
Kernel space
34
Reference Monitor
• Three required properties for reference monitors
in high-assurance systems
– tamper-proof
– non-bypassable (complete mediation)
– small enough to be analyzable
35
Assurance Criteria
• Criteria are specified to enable evaluation
• Originally motivated by military applications, but
now is much wider
• Examples
– Orange Book (Trusted Computer System Evaluation
Criteria)
– Common Criteria
36
TCSEC: 1983–1999
• Trusted Computer System Evaluation Criteria
– Also known as the Orange Book
– Series that expanded on Orange Book in specific
areas was called Rainbow Series
– Developed by National Computer Security Center, US
Dept. of Defense
• Heavily influenced by Bell-LaPadula model and
reference monitor concept
• Emphasizes confidentiality
37
Coming Attractions …
• Integrity Protection
38
