1. A Survey of Formal Models for Computer Security
From a paper by Carl E. Landwehr
Slide assistance from Yu Lin
8/24/2019

2. Outline Why Formal Models? Military Security Effects of Automation
Discussion and Conclusion
8/24/2019

3. Why Formal Models?
Regulations are generally descriptive rather than prescriptive, so they don’t tell you how to implement
Systems must be secure
security must be demonstrable --> proofs
therefore, formal security models
8/24/2019

4. Military Security Classification levels Compartments
unclassified
classified: confidential, secret, top secret
Compartments
topic specific
Clearance - ability to access a certain level/compartment of sensitive information
Compartment X Sensitivity levels, e.g. NUCLEAR secret
Some information may be designated as being in two or more compartments
Security level is sensitivity level plus (possibly empty) set of compartments
Other caveats: ORCON -- originator controlled -- have to have creator’s permission to disseminate, or NOFORN -- not dissemination to non-citizens
Problems with coalition operations
Documents have paragraphs that are individually given classification level
8/24/2019

5. Effects of Automation Automation threats
unauthorized disclosure
unauthorized modification
unauthorized withholding (denial of service)
Automation doesn’t change the threats, but does change patterns of access & enforcement implementation
8/24/2019

6. Historic Problems Aggregation Authentication Integrity Copying
inference problem
Authentication
Integrity
Copying
Denial of Service
8/24/2019

7. New Problems Confinement - prevention of information leakage
legitimate channel
storage channel
covert (timing) channel
Trojan Horses -- program masquerades
Trap-doors --hidden code responds to special input
Other threats (e.g., wiretapping)
8/24/2019

8. Potential Benefits Stricter limits on user discretion
Simplified sanitization of documents
Finer grain protection
sub-divide the document
New kinds of access control
8/24/2019

9. Formal Models - Basic Concepts
Finite state machine model
this structure is the basis for all models in this paper
Lattice model
Access matrix model
Security kernel (small enough for verification)
Information-flow model
FSM: set of states, transition function to determine next state, based on current state and current input value.
Transition may determine output too
8/24/2019

10. Lattice Model (for military application)
Sensitivity levels a, b
Compartments c, d
(a,c) >= (b,d)
iff a >= b and c contains d
Implies greatest lower bound -- (unclass, no compartments
least upper bound -- (top secret, all compartments)
FSM: set of states, transition function to determine next state, based on current state and current input value.
Transition may determine output too
Lattice model
sensitivity levels a, b
compartments c,d
(a,c) >= (b,d) iffi a >= b and c contains d
Implies greatest lower bound -- unclass, no compartments
and least upper bound-- top secret, all compartments
8/24/2019

11. Access Matrix Model Three principal components: object, subject, rules
Access matrix (subject X object)
read, write, append, and execute
Reference monitor - checks each access
Two approaches
capability list (row-wise)
access control list (column-wise)
Domain of a subject is the objects to which it has any access
So access matrix defines domain
Objects are passive; for some purposes, subjects are passive objects
Matrix is the protection state of the system
8/24/2019

12. Access Matrix ... Subjects Objects S1 r r rx rwx kill kill S2 rwx
S3 r rx rx
S4 r r
...
O O O O S S
8/24/2019

13. Take-Grant Model Use graphs to model access control
Access right: read, write, take, grant
Each directed arc represents a capability
arc from one object to another
labeled with access right
Compact representation of sparse access matrix
8/24/2019

14. Take-Grant Model (cont)
Set of rules for rewriting graph
E.g. take rule: A has take right to B, then A can acquire all rights to any object that B has
Rules control deletion & creation of arcs, objects
8/24/2019

15. take
read,grant A B C
take
read,grant A C B
read,grant

16. grant
write A B C
grant
write A B C
write

17. Take Grant Model (cont)
Question asked of model: given initial graph plus rules, can A ever get right R to object X?
I.e. question of graph transformation
Undecidable for general graphs
But decidable for specific graphs & rules
Defined predicates: “can know”, “can tell”, “ can steal”
Can Steal -- get access right to object w/o the collusion of another subject who has that right
8/24/2019

18. Bell & LaPadula Model Captures military classification
Use finite state machine
Formally define a state to be secure, then consider transitions (that maintain security)
Uses subjects & objects of access matrix
Adds military security
subject has clearance & current class.n level
each object has a classification
8/24/2019

19. Bell & LaPadula Model (cont)
Four modes of access
read-only, append, execute, and read-write
Ownership -- owner can pass access modes to owned object to other subjects
Core of operating system is a monitor (security kernel) that checks all accesses
Minimum code; prove its properties
In practice, it is difficult to isolate all security-relevant functions to a small kernel
Read-only -- subject can read, but not modify, object
Append -- subject can write object, but not read it
Execute -- subject can execute the object, but not read or write it directly
read-write -- subject an both read and write object
8/24/2019

20. Bell & LaPadula Model(cont’d)
Properties for a state to be secure
simple security property (restricts “reading up”)
the star-property (prohibits “writing down”)
Tranquility principle
no operation may change the classification of an active object
Simple security property: No subject has read access to any object that has classification greater than clearance of subject
Star Property: no subject has
append-access to object whose security level is not at least the current security level of subject.
read-write access to an object whose security level is not equal to the current security level of subject
read access to object whose security level is not, at most, the current security level of subject
8/24/2019

21. Bell and LaPadula Model(cont’d)
Rules of transition: create object, change security level, rescind access, give access, etc
Trusted subjects
not to compromise security even if some accesses violate the star-property
“Flat” set of objects
atomic objects, each with a single classification
no hierarchy
8/24/2019

22. Problems of B-L Model Static representation is restrictive
Although hierarchies of objects are added in later version, no corresponding appropriate set of axioms
No clear guidance to determine trusted processes
In practice, declassification is a problem
8/24/2019

23. Problems of B-L Model(cont’d)
Allow information to be transmitted improperly through control variables (storage channels)
Their final forms don’t contain storage channels, but timing channels can exist
Many operations that are in fact secure will be disallowed by the model
8/24/2019

24. Information-Flow Model
Focus on operations that transfer information between objects
Five components
objects -- hold information
processes -- active agents
security classes -- disjoint classes of information
flow relation -- given 2 classes, determine if information is allowed to flow from one to other
Access control models represent transfer or exercise of access right to objects by subjects.
Information flow models can go down to individual variables in program
Note that variables in the security kernel can be an information path
8/24/2019

25. Information-Flow Model(cont’d)
Flow relation forms a lattice
Information flow (x->y)
explicit -- opn.s causing flow are independent of value of x, e.g. assignment operation, x=y
implicit -- conditional assignment (if x then y=z)
A program is secure if it does not specify any information flows that violate the given flow relation
Info flow. Info flows from x to y if information stored in x is transferred directly to y, or used to derive information transferred to y
Implicit flow -- info about x flows to whether or not if stmt succeeds
8/24/2019

26. Information-Flow Model(cont’d)
Program is secure if it does not specify any information flows that violate the given flow relation
Consider static binding vs dynamic binding
8/24/2019

27. Programs as Channels for Information Transmission
Each of the models views a program as a medium for information transmission
Key question
what information is conveyed by the execution of a program?
what deductions about protected information are possible?
8/24/2019

28. Programs as Channels for Information Transmission(cont’d)
Filters (Jones and Lipton)
views policy as function that maps from input domain of program to some subset of that domain
protection mechanism as a filter that assures that policy is followed
8/24/2019

29. Discussion and Conclusion
Each model defines its own world and its own concept of security in that world
Appropriateness of a particular model depends on the application for which it is to be used
8/24/2019

30. Discussion & Conclusion(cont’d)
Common problem: an operation is either secure or not
not helpful in making trade-offs between security and performance
not true in the physical world, e.g. “safes’
Formal verification or security properties of systems is an active research topic
Most assume a security kernel
8/24/2019

31. Discussion & Conclusion(cont’d)
Models can be divided into three groups
controlling direct access to objects
information flows among objects
an observer’s ability to make inference
Formal models of computer security are needed in order to ask or answer whether a computer system is secure
8/24/2019

32. Backups
8/24/2019

33. High Water Mark Model Early ADEPT-50 security model “History Function”
objects: users, terminals, jobs, files
property triple (authority, category, franchise)
“History Function”
Problems
“downward” flow
Routine over-classification
8/24/2019

34. UCLA Data Secure UNIX Model
Kernel enforces data security - only access by explicit permission
Policy manager
grant capability
Finite state machine model
state defined by process objects, protection-data objects, general objects, current-process name object
8/24/2019