Download Trusted Operating Systems

Lecture 21
Trusted Operating Systems
CS 450/650
Fundamentals of
Integrated Computer Security
Slides are modified from Hesham El-Rewini
What is a Trusted System?
• Functional correctness
• Enforcement of integrity
• Limited privilege
• Appropriate confidence level
CS 450/650 Fundamentals of Integrated Computer Security
2
Security Policy
• A security policy is a statement of the security
we expect the system to enforce
• A system can be trusted only in relation to its
security policy
– that is, to the security needs the system is
expected to satisfy
CS 450/650 Lecture 21: Trusted Operating System
3
Military Security policy
Unclassified
Restricted
Confidential
Secret
Top
Secret
CS 450/650 Lecture 21: Trusted Operating System
4
Access to Information
• Information access is limited by the need-toknow rule
• Compartment: Each piece of classified
information may be associated with one or
more projects called compartments
CS 450/650 Lecture 21: Trusted Operating System
5
Compartments and Sensitivity Levels
Compartment 1
Top Secret
Secret
Compartment 3
Compartment 2
Confidential
Restricted
Unclassified
CS 450/650 Lecture 21: Trusted Operating System
6
Classification & Clearance
• <rank; compartments>
– class of a piece of information
• Clearance: an indication that a person is
trusted to access information up to a certain
level of sensitivity
• <rank; compartments>
– clearance of a subject
CS 450/650 Lecture 21: Trusted Operating System
7
Dominance Relation
• We say that s dominates o (or o is dominated
by s) if o <= s
For a subject s and an object o,
o <= s if and only if
rank(o) <= rank(s) and
compartments(o) is subset of compartments(s)
• A subject can read an object if the subject
dominates the object.
CS 450/650 Lecture 21: Trusted Operating System
8
Example
• Information classified as <secret; {Sweden}>
• Which of the following subject clearances can
read the above information?
– <top secret; {Sweden}>
– <secret; {Sweden, crypto}>
– <top secret; {crypto}>
– <confidential; {Sweden}>
– <secret; {France}>
CS 450/650 Lecture 21: Trusted Operating System
9
Models of Security
• Security models are used to
– Test a particular policy for completeness and
consistency
– Document a policy
– Help conceptualize and design an implementation
– Check whether an implementation meets the
requirements
CS 450/650 Lecture 21: Trusted Operating System
10
Lattice Model
Upper bound
Lower bound
CS 450/650 Lecture 21: Trusted Operating System
11
Bell-La Padula Model
• Formal description of the allowable paths of
information flow in a secure system
• Set of subjects and another set of objects
• Each subject s has a fixed security clearance C(s)
• Each object o has a fixed security class C(o)
CS 450/650 Lecture 21: Trusted Operating System
12
Bell-La Padula Model
• Two properties characterize the secure flow of
information:
– A subject s may have read access to an object o
only if C(o) <= C(s)
– A subject s who has read access to an object o
may have write access to an object p only if
C(o) <= C(p)
• Prevents write-down
CS 450/650 Lecture 21: Trusted Operating System
13
Illustration
High
o5
Write
Read
s2
o4
Read
o3
Write
o5
Object
s2
Subject
Read
s1
o2
Read
o1
CS 450/650 Lecture 21: Trusted Operating System
Low
14
Harrison, Ruzzo, and Ullman Model
S1
S1
S2
S3
O1
control
S2
O2
O3
Owner
read
control
S3
control
Owner
Read
write
read
Owner
execute
read
read
execute
• Command
– Conditions and primitive operations
CS 450/650 Lecture 21: Trusted Operating System
15
HRU Model (cont.)
• HRU allows state of the protection system to
be changed by a well defined set of
commands:
– Add subject s to M
– Add object o to M
– Delete subject s from M
– Delete object o from M
– Add right r to M[s,o]
– Delete right r from M[s,o]
– Owner can change rights of an object
CS 450/650 Lecture 21: Trusted Operating System
16
Take Grant Model
• Unlimited number of subjects and objects
• States and state transitions
• Directed graph
• Four primitive operations:
– take
– create
– grant
– revoke
CS 450/650 Lecture 21: Trusted Operating System
17
Take Grant Model (Cont.)
S2
O2
read
execute
read
S1
Read, write
O1
O3
read
execute
S3
CS 450/650 Lecture 21: Trusted Operating System
18
Create
S
S
O
becomes
rights
CS 450/650 Lecture 21: Trusted Operating System
19
Revoke
S
S
O
O
becomes
r1, r2, r3
CS 450/650 Lecture 21: Trusted Operating System
r1, r2
20
Take
S1
S2
take
O
read
becomes
read
S1
S2
take
CS 450/650 Lecture 21: Trusted Operating System
read
O
21
Grant
read
S1
S2
O
grant
becomes
read
S1
S2
grant
CS 450/650 Lecture 21: Trusted Operating System
read
O
22
CS 450/650 Fundamentals of Integrated Computer Security
23
Trusted OS Design
• OS is a complex system
– difficult to design
– Adding the responsibility of security enforcement
makes it even more difficult
• Clear mapping from security requirements to
the design
• Design must be checked using formal reviews
or simulation
• Requirements  design  testing
CS 450/650 Lecture 21: Trusted Operating System
24
Security Design Principles
• Least privilege
– users, programs, fewest privilege possible
• Economy of mechanism
– small, simple, straight forward
• Open design
– extensive public scrutiny
• Complete mediation
– every attempt must be checked
CS 450/650 Lecture 21: Trusted Operating System
25
Security Design Principles
• Permission based
– denial of access is the default
• Separation of privilege
– more than one condition
• Least common mechanism
– the risk of sharing
• Ease of use
– unlikely to be avoided
CS 450/650 Lecture 21: Trusted Operating System
26
OS Functions
CS 450/650 Lecture 21: Trusted Operating System
27
Security features in ordinary OS
• Authentication of users
– password comparison
• Protection of memory
– user space, paging, segmentations
• File and I/O device access control
– access control matrix
• Allocation & access control to general objects
– table lookup
CS 450/650 Lecture 21: Trusted Operating System
28
Security features in ordinary OS
• Enforcement of sharing
– integrity, consistency
• Fair service
– no starvation
• Interprocess communication & synchronization
– table lookup
• Protection of OS protection data
– encryption, hardware control, isolation
CS 450/650 Lecture 21: Trusted Operating System
29
Trusted OS Functions
CS 450/650 Lecture 21: Trusted Operating System
30
Security features of Trusted OS
•
•
•
•
•
•
•
•
Identification and Authentication
Mandatory and Discretionary Access Control
Object reuse protection
Complete mediation (all accesses are checked)
Trusted path
Accountability and Audit (security log)
Audit log reduction
Intrusion detection (patterns of normal system
usages, anomalies)
CS 450/650 Lecture 21: Trusted Operating System
31
Kernel
• OS part that performs lowest level functions
User tasks
OS
OS Kernel
Hardware
CS 450/650 Lecture 21: Trusted Operating System
32
Security Kernel
• responsible for enforcing security mechanisms
of the entire OS
• Coverage
– ensure that every access is checked
• Separation
– security mechanisms are isolated from the rest of
OS and from user space  easier to protect
• Unity
– all security mechanisms are performed by a single
set of code  easier to trace problems
CS 450/650 Lecture 21: Trusted Operating System
33
Security Kernel
• Modifiability
– security mechanism changes are easier to make
and test
• Compactness
– relatively small
• Verifiability
– formal methods , all situations are covered
CS 450/650 Lecture 21: Trusted Operating System
34
Reference Monitor
• portion of a security kernel that controls
accesses to objects
• Collection of access controls for
– Devices, Files, Memory, Interprocess
communication, Other objects
Gate
• It must be
O
O
O
S
S
S
– Always invoked when any object is accessed
– Small enough
• analysis, testing
– Tamperproof
CS 450/650 Lecture 21: Trusted Operating System
35
Trusted Computing Base (TCB)
• Everything in the trusted OS necessary to
enforce security policy
• System element on which security
enforcement depends:
– Hardware
• processors, memory, registers, and I/O devices
– Processes
• separate and protect security-critical processes
CS 450/650 Lecture 21: Trusted Operating System
36
Trusted Computing Base (TCB)
• System element on which security
enforcement depends (cont):
– Primitive files
• security access control database,
identification/authentication data
– Protected memory
• reference monitor can be protected against tampering
– Interprocess communication
• e.g., reference monitor can invoke and pass data
securely to audit routine
CS 450/650 Lecture 21: Trusted Operating System
37
TCB and Non-TCB Code
Applications
Utilities
Non-TCB
User request interpreter
…
Segmentation, paging, memory management
Primitive I/O
Basic Operations
Clocks, timing
Interrupt handling
Hardware:registers memory
Capabilities
CS 450/650 Lecture 21: Trusted Operating System
TCB
38
TCB monitors basic interactions
• Process activation
• Execution domain switching
• Memory Protection
• I/O operation
CS 450/650 Lecture 21: Trusted Operating System
39
Combined Security Kernel / OS System
OS Kernel:
- HW interactions
- Access control
User tasks
OS
OS Kernel
Hardware
OS:
- Resource allocation
- Sharing
- Access control
- Authentication functions
CS 450/650 Lecture 21: Trusted Operating System
Security activity
40
Separate Security Kernel
Security Kernel:
-Access control
-Authentication functions
User tasks
OS
Security Kernel
Hardware
OS:
- Resource allocation
- Sharing
- Hardware interactions
CS 450/650 Lecture 21: Trusted Operating System
41
Separation
• Physical Separation
• Temporal Separation
• Cryptographic Separation
• Logical separation (isolation)
CS 450/650 Lecture 21: Trusted Operating System
42
Virtualization
• OS emulates or simulates a collection of a
computer system’s resources
• Virtual Machine: Collection of real or
simulated hardware facilities
– processor, memory, I/O devices
CS 450/650 Lecture 21: Trusted Operating System
43
Virtual machine
Virtual
Machine
Virtual
Machine
Virtual
Machine
User 1
User 2
User 3
Real OS
Real System Resources
CS 450/650 Lecture 21: Trusted Operating System
44
Layered OS
User processes
Compilers, database
OS
Utility functions
File system, device allocation
Scheduling, sharing, MM
Synchronization, allocation
Security kernel
OS kernel
Security functions
Hardware
CS 450/650 Lecture 21: Trusted Operating System
47
Modules operating in Different Layers
Least trusted code
Most
trusted code
Data update
Data comparison
User ID lookup
User Authentication module
CS 450/650 Lecture 21: Trusted Operating System
User interface
48
Assurance
• Testing
– based on the actual product being evaluated,
• not on abstraction
• Verification
– each of the system’s functions works correctly
• Validation
– developer is building the right product
• according to the specification
CS 450/650 Lecture 21: Trusted Operating System
49
Testing
• Observable effects versus internal structure
• Can demonstrate existence of a problem, but
passing tests does not imply absence of any
• Hard to achieve adequate test coverage within
reasonable time
– inputs & internal states
• hard to keep track of all states
• Penetrating Testing
– tiger team analysis, ethical hacking
• Team of experts in design of OS tries to crack system
CS 450/650 Lecture 21: Trusted Operating System
50
Formal verification
• The most rigorous method
• Rules of mathematical logic to demonstrate
that a system has certain security property
• Proving a Theorem
– Time consuming
– Complex process
CS 450/650 Lecture 21: Trusted Operating System
51
Example: find minimum
Entry
min  A[1]
i1
ii+1
yes
Exit
i>n
no
yes
min < A[i]
no
min  A[i]
CS 450/650 Lecture 21: Trusted Operating System
52
Finding the minimum value
Assertions
P: n > 0
Q:
R: n > 0 and
S:
1  i  n and
for all j 1  j  i -1
min  A[j]
CS 450/650 Lecture 21: Trusted Operating System
n > 0 and
1  i  n and
min  A[1]
n > 0 and
i = n + 1 and
for all j 1  j  i -1
min  A[j]
53
Validation
• Requirements checking
– system does things it should do
• also, system does not do things it is not supposed to do
• Design and code reviews
– traceability from each requirement to design and
code components
• System testing
– data expected from reading the requirement
document can be confirmed in the actual running
of the system
CS 450/650 Lecture 21: Trusted Operating System
54