State State Transition
State State Transition
State – Representation of the system at some given time Most famous security model
State transition – next state depends on current state + input. First developed around 1973
Idea: If we start in a secure state and all state transitions ”Unified exposition and Multics interpretation”, 1976
preserve security, then the system will be secure.
Focus on confidentiality, not integrity
Based on state transitions
Question 1:
What is a state?
Both mandatory and discretionary access control
◦ Multilevel security
◦ Access control matrix
Question 2:
What is a secure state?
1
2013-02-15
The state consists of three parts (in our book) We have a system with 5 subjects and 5 objects, 2
classifications and 2 categories
1. Current access operation given by a set of (s,o,a) tuples ◦ Subjects: Alice, Bob, Charlie, David, Erika
◦ An element of the powerset P(S ☓ O ☓ A) ◦ Objects: file_a, file_b, file_c, file_d, file_e
◦ Can be written as matrix b.
◦ Classifications : public, private
◦ s is row, o is column, a is current access operation
◦ Categories: A, B
2. Access matrix given by M
3. Functions f = (fS, fC, fO)
State is given by ( b, M, f )
Note: Usually the set of all objects is also a part of the state,
but our book ignores this
2
2013-02-15
Current access set b file_a file_b file_c file_d file_e Mandatory access control Alter X X
3
2013-02-15
(David, file_c, w)
Does not apply to trusted subjects (Erika, file_a, a)
Charlie r r a
David r,w,a r,w,a
Erika a e
State (b,M,f) satisfies the *-property if for each
element (s,o,a) ∈ b where the access operation a Functions f = (fS, fC, fO)
fS :
is append or write, the current security level of s Alice: (private, {A}), Bob: (public, {A,B}), Charlie: (public, {B}), David: (private, {A,B}), Erika: (public, {A})
is dominated by the security level of o, i.e., fC(s) fC :
≤ fO(o) Alice: (private, {A}), Bob: (public, {A,B}), Charlie: (public, {B}), David: (public, {A,B}), Erika: (public, {A})
fO :
file_a: (private, {A}), file_b: (private, {∅}), file_c: (public, {A,B}), file_d: (public, {A}), file_e: (private, {A,B})
ss-property considers maximum level of subject – fS(s) Result: It would be possible for information to flow
*-property considers current level of subject fC(s) from file_e to file_c
David has append access to file_c, but he would also be
granted read access to file_e file_e (private, {A,B})
read
append
file_c (public, {A,B})
4
2013-02-15
State (b,M,f) satisfies the *-property if for each element Subject may pass an access permission on to other
(s,o,a) ∈ b where the access operation a is append or write, users.
the current security level of s is dominated by the security
level of o, i.e., fC(s) ≤ fO(o) Discretionary access control
5
2013-02-15
object o
Change current level – change value of fC(s) for
} Change f in state
enter all access rights in all entries of M
→ Everyone can do everything – not secure
subject s
Give access permission – add an access operation Bell standpoint:
to M
Rescind access permission – remove an access
operation from M
} Change M in state
If such a transition is required, it should be ok.
Otherwise, it should not be implemented.
Create object – add an object to system
Remove object – remove an object from system } Not supported by
”our” state
Tranquility: security levels and access rights never change.
Only focus on confidentiality, not integrity Focuses on integrity, i.e., unauthorized modification
Not addressing management of access control of data
Proposed in 1977
Contains covert channels – information flow not controlled by
Similar to Bell-LaPadula in several ways
the security mechanisms.
Example:
◦ Based on multilevel security with a partial ordering
◦ Low level subject creates file.txt at low level ◦ Based on subjects and objects
◦ High level subject upgrades file.txt to higher level, or leaves it alone Subjects and objects mapped to integrity levels
◦ Low level subject tries to read file.txt
forming a lattice
Example 2:
◦ fS : S → L subject integrity level
◦ If low-level subjects can read filenames at high levels the filename can
also be used to send information from high-level subjects ◦ fO : O → L object integrity level
6
2013-02-15
private, {∅}
Object low watermark property
public, {A,B}
Subject s can modify an object o at any integrity Alice (private, {∅})
level. The new integrity level of the object is the time t+1: read
public, {A}
greatest lower bound of fS(s) and fO(o). file_a (private, {B})
public, {B}
public, {∅}
EIT060 - Computer Security 27 EIT060 - Computer Security 28
7
2013-02-15
Object low watermark policy A subject may invoke another subject to access an object
private, {A,B}
Invoke property
Alice (public, {A}) private, {A} Subject s1 can invoke subject s2 only if fS(s2) ≤ fS(s1)
time t: modify private, {B}
file_a (private, {B}) Only invoke subjects (e.g., software tools) at lower levels
◦ Otherwise dirty subjects could use clean tools to alter clean objects
private, {∅}
◦ But maybe this is what we want? Controlled invocation!
public, {A,B} Ring property
Alice (public, {A})
time t+1: modify
public, {A}
file_a (public, {∅}) A subject s1 can read all objects. It can only
public, {B}
modify objects with fO(o) ≤ fS(s1) and it can
invoke subject s2 only if fS(s1) ≤ fS(s2)
public, {∅}
EIT060 - Computer Security 29 EIT060 - Computer Security 30
8
2013-02-15
Two kinds of data items Certification rule 1: IVPs must ensure that all CDIs are in a valid state
◦ Constrained data items (CDI) – data items subject to integrity control. Certification rule 2: A TP has an associated set of CDIs. TP must
transform these CDIs from valid states to valid states.
E.g., account balances.
◦ Unconstrained data items (UDI) – data items not subject to integrity
CR2 implies that nonassociated CDIs can be corrupted by a TP.
control. E.g., unimportant text files
Enforcement rule 1: System must maintain list of CDIs associated to
Integrity verification procedures (IVP) – check the integrity of each TP. Only these CDIs can be manipulated by this TP.
CDIs. E.g., check that account balance is what it should be
Transformation procedures (TP) – changes the state of the Not everyone should be able to run any TP
Enforcement rule 2: System must associate a list of TPs with each user.
system, i.e., manipulates CDIs. E.g., deposit money, withdraw A TP can not be run by a user not associated with that TP.
money, transfer money
Certification rules – How should the system behave Now we have a set of triples (user, TP, {CDI set}). These must be certified.
Certification rule 3: All triples must meet the separation of duties
Enforcement rules – How do we make the system behave the requirements
way we want
Only certain users are allowed to run a certain TP. How do we know the
user is who he claims to be?
Enforcement rule 3: The system must authenticate each user trying
to execute a TP.
9
2013-02-15
CI class CI class
Bank Bank
A B An analyst with access to grey
shaded areas, will have access
to other objects in Bank A data Analyst A updates bank information about company A
set, but not Bank B dataset
Analyst B can read this bank information and write to an
object in company B
EIT060 - Computer Security 39 EIT060 - Computer Security 40
10
2013-02-15
11