lattice-based access control models 1 daniel trivellato
TRANSCRIPT
Lattice-based Access Control Models 1
Daniel Trivellato
23/09/2008 DTM course - Daniel Trivellato 2
Outline
Review: DAC and the access matrix Mandatory access control and the lattice Multi-level security: the Bell-LaPadula (BLP)
model Applications of BLP
23/09/2008 DTM course - Daniel Trivellato 3
Outline
Review: DAC and the access matrix Information flow policies and the lattice Multi-level security: the Bell-LaPadula (BLP)
model Applications of BLP
23/09/2008 DTM course - Daniel Trivellato 4
Information security objectives
Information security has 3 objectives: confidentiality (or secrecy), related to
disclosure of information integrity, related to modification of information availability, related to denial of access to
information
23/09/2008 DTM course - Daniel Trivellato 5
Access Control (AC)
Goal: protect data and resources from unauthorized use
Policy: defines rules (high-level) describing the accesses to be authorized by the system
Model: formally defines the AC specification and enforcement
Mechanism: implements the policies via low level (software and hardware) functions
23/09/2008 DTM course - Daniel Trivellato 6
AC requirements
Correctness of AC relies on proper user identification/authentication
Mechanism based on the definition of a reference monitor which must be tamper-proof non-bypassable confined in a limited part of the system (security
kernel) verifiable
23/09/2008 DTM course - Daniel Trivellato 7
Discretionary Access Control (DAC) policies
explicit access rules establish who can execute which actions on which resource
users can pass on their rights to other users
granting and revocation of rights regulated by an administrative policy (centralized vs. ownership)
23/09/2008 DTM course - Daniel Trivellato 8
Access matrix model (1/2)
authorization state is represented as a matrix the system state is a triple (S,O,A), where
S is a set of subjects O is a set of objects A is an access matrix, where
rows correspond to subjects columns correspond to objects A[s,o] describes the privileges of s on o
23/09/2008 DTM course - Daniel Trivellato 9
Access matrix - Example
File 1 File 2 File 3 Program 1
Alice
own
read
write
read
write
Bob readread
writeexecute
Charlie readexecute
read
23/09/2008 DTM course - Daniel Trivellato 10
Access matrix model (2/2)
Changes of states via commands calling primitive operations: enter r into A[s,o] delete r from A[s,o] create subject s’ destroy subject s’ create object o’ destroy object o’
23/09/2008 DTM course - Daniel Trivellato 11
DAC weaknesses (1/2)
DAC is very flexible but…
Alice owns a file, she wants Bob to read it, but not Charlie
in DAC, Bob can leak the information to Charlie (even without being aware of it)
how?
Trojan horse: software containing hidden code that
performs (illegitimate) functions not known to the caller
Trojan horses
23/09/2008 DTM course - Daniel Trivellato 12
Trojan horse - Example
Bob invokes
Application (e.g. calendar)
read contactswrite stolen
code
malicious code
File contacts
owner Bob
Alice 06-12345678Charlie 06-23456781
File stolen
owner Daniel
Alice 06-12345678Charlie 06-23456781
(Bob,write,stolen)
23/09/2008 DTM course - Daniel Trivellato 13
DAC weaknesses (2/2)
DAC constraints only direct access, no control on what happens to information after release
Trojan horses exploit access privileges of calling subjects
covert channels (later)
23/09/2008 DTM course - Daniel Trivellato 14
Outline
Review: DAC and the access matrix Mandatory Access Control and the lattice The Bell-LaPadula (BLP) model Applications of BLP
23/09/2008 DTM course - Daniel Trivellato 15
Mandatory Access Control (MAC) policies
goal: prevent the illegitimate flow (leakage) of information
idea: attach security labels to subject and objects
Makes a distinction between users and subjects acting on their behalf we can trust the users, but not the subjects
23/09/2008 DTM course - Daniel Trivellato 16
Military security (1/3)
Initially (‘70s) most research in information security was applied to the military domain
need to protect information that, if known by an enemy, might damage national security
protecting information is costly
23/09/2008 DTM course - Daniel Trivellato 17
Military security (2/3)
different sensitivity levels (hierarchical) are assigned to information unclassified (= public) (restricted) < confidential < secret < top secret
a clearance is assigned to individuals (reflects their trustworhtiness)
Example: in the USA, a ‘secret’ clearance involves checking FBI fingerprint files, ‘top secret’ also involves background checks for the previous 5-15 years of employment
23/09/2008 DTM course - Daniel Trivellato 18
Military security (3/3) an individual has not to be aware of all
information at a given sensitivity level finer grained classification on the basis of the
need to know information about different areas divided into
separate compartments (e.g. nuclear, chemical), possibly overlapping
the classification (security class) of an object is a tuple (sensitivity level,{compartment})
23/09/2008 DTM course - Daniel Trivellato 19
Information flow policies (1/2)
defined by Denning (’76) concerned with the flow of information from
one security class to another information flow as an ordering relation instead of a list of axioms governing users’
accesses, simply require that information transfers obey the ordering relation
23/09/2008 DTM course - Daniel Trivellato 20
Information flow policies (2/2)
SC is a set of security classes may_flow is a relation on SC x SC ‘+’ is a function from SC x SC to SC An information flow policy is a triple
<SC,may_flow,+>
Example: SC = {(S,{nuclear,chemical}), (S,{nuclear}), (S,{chemical})} (S,{nuclear}) may_flow (S,{nuclear,chemical}); (S,{nuclear}) + (S,{chemical}) = (S,{nuclear,chemical})
23/09/2008 DTM course - Daniel Trivellato 21
Information flow - Example Consider a company in which line managers report income to two
different superiors - a business manager and an auditor. The auditor and the business manager are independent. Information may_flow from the workers to the line managers, and from the line managers to the business manager and the auditor.
23/09/2008 DTM course - Daniel Trivellato 22
Orders and lattice (1/2)
partial order of a set: binary relation that is transitive: a ≥ b and b ≥ c then a ≥ c reflexive: a ≥ a anti-symmetric/acyclic: a ≥ b and b ≥ a then a = b
total order: like a chain (either a ≥ b or b ≥ a)
lattice: every subset has a least upper bound, and a greatest lower bound
23/09/2008 DTM course - Daniel Trivellato 23
Orders and lattice (2/2)
Hasse diagrams depict a partial order
(e) is not a lattice
23/09/2008 DTM course - Daniel Trivellato 24
Information flow - Example Consider a company in which line managers report income to two
different superiors - a business manager and an auditor. The auditor and the business manager are independent. Information may_flow from the workers to the line managers, and from the line managers to the business manager and the auditor.
may-flow depicted below is not a lattice
23/09/2008 DTM course - Daniel Trivellato 25
Classification lattice - Example Levels: TS, S and TS > S
lub((TS, {Nuclear}), (S, {Nuclear, Chemical})) = glb((TS, {Nuclear}), (S, {Nuclear, Chemical})) =
(TS, {Nuclear, Chemical})
(S, {Nuclear})
TS, {Nuclear, Chemical}
TS, {Nuclear} TS, {Chemical}S, {Nuclear, Chemical}
TS, {}
S, {}
S, {Nuclear} S, {Chemical}
the partial order on security classes is called dominates(L1,C1) ≥ (L2,C2) iff L1 ≥ L2 and C2 C C1
Compartments: Nuclear, Chemical
23/09/2008 DTM course - Daniel Trivellato 26
Denning’s axioms
under the following assumptions, an information flow policy forms a finite lattice:
1. the set of security classes SC is finite
2. the may-flow relation is a partial order on SC
3. SC has a lower bound w.r.t. may_flow
4. operator + is a totally defined least upper bound operator
23/09/2008 DTM course - Daniel Trivellato 27
Outline
Review: DAC and the access matrix Mandatory Access Control and the lattice The Bell-LaPadula (BLP) model Applications of BLP
23/09/2008 DTM course - Daniel Trivellato 28
The BLP model
formalizes mandatory policy for secrecy goal: prevent information flow to lower or
incomparable security classes multi-level security
idea: augment DAC with MAC (security labels) to enforce information flow policies
two-step approach1. discretionary access matrix D2. operations authorized by MAC policy, over
which users have no control
23/09/2008 DTM course - Daniel Trivellato 29
BLP mandatory access rules
object o has security label (class) SL(o) subject s has security label (clearance) SL(s) simple security property: subject s can read
object o only if SL(s) ≥ SL(o) *-property: subject s can write object o only if
SL(o) ≥ SL(s)
NO READ UPNO WRITE DOWN
Trojan horses leaking information are blocked
23/09/2008 DTM course - Daniel Trivellato 30
BLP information flow
SUBJECTS OBJECTS
…….....
…….....
…….....
…….....
TS
S
C
U
Info
rma
tion
flow
TS
S
C
U
writ
e
read
writ
e
read
writ
e
read
writ
e
read
23/09/2008 DTM course - Daniel Trivellato 31
BLP - Secure states system modeled as a finite state machine (set of
states and transition of states) a state contains information about the current
authorizations and security labels a transition transforms a state into another state
(adding or removing authorizations) a state is secure if the current authorizations satisfy
the simple and * security properties a system is secure if every state reachable by
executing a finite sequence of transitions is secure
23/09/2008 DTM course - Daniel Trivellato 32
BLP + tranquility
Assume that when a subject request access to a resource the security levels of all subjects and objects are downgraded to the lowest level and access is granted
secure by BLP…but not secure in a meaningful sense!!!
Tranquility property strong: security labels never change during system operation
TOO STRONG! weak: labels never change in such a way as to violate a defined
security policy
e.g. dynamic upgrade of labels principle of least privilege
23/09/2008 DTM course - Daniel Trivellato 33
Exceptions to properties
Data association and aggregation: a set of values seen together is to be classified higher than the single values (e.g. name and salary)
Sanitization and downgrading: a process may produce data less sensitive than those it has read; data may need to be downgraded after some time (embargo)
TRUSTED SUBJECTS!
23/09/2008 DTM course - Daniel Trivellato 34
MAC weaknesses MAC policies remain vulnerable to covert
channels Examples
a low level subject requires a resource (e.g. CPU) that is busy by a high level subject
a high level process can lock shared resources and modify the response times of processes at lower levels (timing channels)
non-interference: the activity of a high level process must have no detectable effect on processes at lower or incomparable level
23/09/2008 DTM course - Daniel Trivellato 35
Outline
Review: DAC and the access matrix Mandatory Access Control and the lattice The Bell-LaPadula (BLP) model Applications of BLP
23/09/2008 DTM course - Daniel Trivellato 36
Real world examples
MULTICS for the Air Force Data Services Centre (time-sharing OS)
MITRE brassboard kernel SIGMA message system KSOS (Kernelized Secure Operating System) SCOMP (Secure Communications Processor) PSOS (Provably Secure Operating System) SELinux multi-level Database Management Systems
23/09/2008 DTM course - Daniel Trivellato 37
KSOS
a system is multi-level secure if, for any two processes HIGH and LOW, HIGH can do nothing to affect in any way the operation of LOW LOW can know nothing of HIGH
security levels associated with function references and state variables
no result of any function at a low level should depend from a higher level variable/function
23/09/2008 DTM course - Daniel Trivellato 38
SELinux (NSA) a security context contains all security
attributes associated with subject and objects policy decisions are made by a security
server residing in-kernel (no kernel-userspace calls for security decisions)
the server provides a security API to the rest of the kernel, with security model hidden behing this API
mechanisms to isolate different services running on a machine
23/09/2008 DTM course - Daniel Trivellato 39
Multi-level DBMSs
in an OS security class is assigned to files or programs
DBMS can afford a finer grained classification relation attribute tuple element
commercial ML-DBMS (e.g. Oracle) support classification at the level of tuple
23/09/2008 DTM course - Daniel Trivellato 40
ML-DB – Example (element)
Name LN Dept LD Salary LS
Alice U Dept1 U 100K U
Bob S Dept2 S 200K S
Charlie U Dept2 U 150K S
23/09/2008 DTM course - Daniel Trivellato 41
ML-DBMSs - Polyinstantiation
Access control must obey to BLP principlesA. A low level subject requests to insert a tuple already
existing with a higher classificationB. A high level subject requests to insert a tuple
already existing with a lower classification 3 possible solutions:
tell the subject
replace the old tuple
insert a new tuple
A. information leakageB. denial of serviceA. loss of integrityB. information leakageA. polyinstantiated tupleB. polyinstantiated tuple
23/09/2008 DTM course - Daniel Trivellato 42
Polyinstantiation - Example
Name LN Dept LD Salary LS
Alice U Dept1 U 100K U
Bob S Dept2 S 200K S
Charlie U Dept2 U 150K S
Request by an U-subject:
UPDATE Employee SET Salary=‘100K’ WHERE Name=‘Charlie’
Name LN Dept LD Salary LS
Alice U Dept1 U 100K U
Bob S Dept2 S 200K S
Charlie U Dept2 U 150K S
Charlie U Dept2 U 100K U
23/09/2008 DTM course - Daniel Trivellato 43
Polyinstantiation - Example
Name LN Dept LD Salary LS
Alice U Dept1 U 100K U
Bob S Dept2 S 200K S
Charlie U Dept2 U 150K S
Request by a S-subject:
INSERT INTO Employee VALUES (Alice, Dept1, 150K)
Name LN Dept LD Salary LS
Alice U Dept1 U 100K U
Bob S Dept2 S 200K S
Charlie U Dept2 U 150K S
Alice S Dept1 S 150K S
23/09/2008 DTM course - Daniel Trivellato 44
ML-DBMSs - Cover stories
Polyinstantiation is blaimed to be one of the main reasons why multi-level DBMSs have not succeeded…it quickly goes out of hand
however, it is useful to support cover stories cover story: incorrect values returned to a low
level subject to protect the real value (useful when returning restricted/null would leak information)
23/09/2008 DTM course - Daniel Trivellato 45
ML-DBMSs - Architecture trusted subject: data stored in a single DB
the DBMS must be trusted
trusted computing base: data are partitioned in different DBs only OS needs to be trusted DBMS access data that can be read at its level
Low subject
High subject
TRUSTED DBMS
TRUSTED OS
ML-DB
….Low
subjectHigh subject
High DBMS
TRUSTED OS
Low DB
……..
Low DBMS
High DB
...
...
23/09/2008 DTM course - Daniel Trivellato 46
Summary
DAC: users have the ability to pass on their rights to other users based on the access matrix model no control on information after release: vulnerable
to information leakage (e.g. Trojan horses) MAC: prevents illegitimate flow of information
by attaching security labels to subjects and objects distinction between users (trusted) and subjects
(i.e. processes, not trusted)
23/09/2008 DTM course - Daniel Trivellato 47
Summary
Lattice: the partial order of security classes forms a lattice structure
BLP: augments DAC with MAC to prevent information flow to lower or incomparable classes NO READ UP NO WRITE DOWN
23/09/2008 DTM course - Daniel Trivellato 48
Exercises
Does DAC prevent information leakage? Why? And what about MAC, does it always prevent information leakage?
Construct a lattice of security classes for security levels public < secret < top-secret and compartments {army, politics, business}
How many security classes can be constructed with n security levels and m compartments?
23/09/2008 DTM course - Daniel Trivellato 49
Exercises
Can a user cleared for (S, {dog, cat, pig}) access to documents classified in the following ways under the military information flow model? (TS, {dog}) (S, {dog}) (S, {dog, cow}) (S, {monkey}) (C, {dog, pig, cat}) (C, { })
23/09/2008 DTM course - Daniel Trivellato 50
Exercises What policy is adopted in the standard
Windows implementations? Consider two subjects s1 and s2, with security
classification TS and S respectively. Are the following operations authorized according to BLP, and if not, why?
1. s1 requests to write a S-object o1 (refer to the tranquility principle)
2. s2 requests to read o1
3. s1 requests to send a TS-object o2 to s2
4. s1 requests to copy the content of o2 to o1
23/09/2008 DTM course - Daniel Trivellato 51
Exercises
What is the security class of an object obtained by aggregating the content of a S- and a TS-object?
Describe a situation in which you may want to allow the security kernel to violate one of the security properties of BLP
23/09/2008 DTM course - Daniel Trivellato 52
References
Ravi S. Sandhu – Lattice-Based Access Control Models (strongly recommended)
Carl E. Landwehr – Formal Models for Computer Security (strongly recommended)
Pierangela Samarati, Sabrina De Capitani di Vimercati - Access Control: Policies, Models, and Mechanisms (recommended)
Ross Anderson – Security Engineering (2nd Edition) (suggested)
Thank you for your [email protected]