Upload
amelia-patterson
View
218
Download
1
Tags:
Embed Size (px)
Citation preview
Lecture 20 Overview
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
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
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
OS Functions
5
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
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
Trusted OS Functions
8
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)
Kernel
• OS part that performs lowest level functions
User tasks
OS
OS Kernel
Hardware
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
Security Kernel
• Modifiability– security mechanism changes are easier to make
and test
• Compactness– relatively small
• Verifiability– formal methods , all situations are covered
Lecture 21
Trusted Operating System
CS 450/650
Fundamentals of Integrated Computer Security
Slides are modified from Hesham El-Rewini
Reference Monitor• portion of a security kernel that controls
accesses to objects• Collection of access controls for– Devices, Files, Memory, Interprocess
communication, Other objects
• It must be– Always invoked when any object is accessed– Small enough
• analysis, testing
– Tamperproof
O
S
O O
SS
Gate
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
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
TCB and Non-TCB Code
Primitive I/O
Basic Operations
Clocks, timing
Interrupt handling
Hardware:registers memory
Capabilities
Applications
Utilities
User request interpreter
…
Segmentation, paging, memory management
TCB
Non-TCB
TCB monitors basic interactions
• Process activation
• Execution domain switching
• Memory Protection
• I/O operation
Combined Security Kernel / OS System
User tasks
OS
OS Kernel
Hardware
Security activity
OS Kernel:
- HW interactions
- Access control
OS:
- Resource allocation
- Sharing
- Access control
- Authentication functions
Separate Security Kernel
User tasks
OS
Security Kernel
Hardware
Security Kernel:
-Access control
-Authentication functions
OS:
- Resource allocation
- Sharing
- Hardware interactions
Separation
• Physical Separation
• Temporal Separation
• Cryptographic Separation
• Logical separation (isolation)
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
Virtual machine
Real System ResourcesReal System Resources
Real OSReal OS
Virtual Virtual
MachineMachine
User 1User 1
Virtual Virtual
MachineMachine
User 2User 2
Virtual Virtual
MachineMachine
User 3User 3
Layered OS
Hardware
Security functions
Synchronization, allocation
Scheduling, sharing, MM
File system, device allocation
Utility functions
Compilers, database
User processes
OS kernel
Security kernel
OS
Modules operating in Different Layers
Least trusted code
Most
trusted code
User interface
User ID lookup
Data comparison
Data update
User Authentication module
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
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
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
Entry
min A[1]
i 1
i i + 1
i > n
min < A[i]
min A[i]
Exityes
noyes
no
Example: find minimum
Finding the minimum value
AssertionsP: n > 0 Q: n > 0 and
1 i n and min A[1]
R: n > 0 and S: n > 0 and1 i n and i = n + 1 and
for all j 1 j i -1 for all j 1 j i -1 min A[j] min A[j]
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
Security Policies
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
Military Security policy
Unclassified
Restricted
Confidential
Secret
Top
Secret
Access to Information
• Information access is limited by the need-to-know rule
• Compartment: Each piece of classified information may be associated with one or more projects called compartments
Compartments and Sensitivity Levels
Unclassified
Restricted
Confidential
Secret
Top SecretCompartment 1
Compartment 3Compartment 2
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
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.
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}>
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
Lattice
Upper bound
Lower bound
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)
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).
Illustration
o1
s1 o2
o3
s2 o4
o5
Low
High
Harrison, Ruzzo, and Ullman Model
S1 S2 S3 O1 O2 O3
S1 control Owner
read
S2 control Owner
Read
write
read Owner
execute
S3 control read read execute
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
Take Grant Model
• Unlimited number of subjects and objects• States and state transitions• Directed graph
• Four primitive operations:– take– create– grant– revoke
Take Grant Model (Cont.)
O2
O1O3
S1
S2
S3
read
read
read
execute
execute
Read, write
Create
OSS
rightsbecomes
Revoke
OS
r1, r2becomes
OS
r1, r2, r3
Take
OS2take
becomes
S1 read
OS2take
S1 read
read
Grant
becomes
OS2grant
S1 read
read
OS2grant
S1
read