Vous êtes sur la page 1sur 46

What is a Trusted System?

• Functional correctness

• Enforcement of integrity

• Limited privilege

• Appropriate confidence level

•CS 450/650 Fundamentals of Integrated


•1
Computer Security
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


•2
System
Military Security policy
Unclassified

Restricted
Confidential
Secret

Top
Secret

•CS 450/650 Lecture 21: Trusted Operating


•3
System
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
Compartment 1 Top Secret
Secret
Compartment 2
Compartment 3 Confidential
Restricted
Unclassified
•CS 450/650 Lecture 21: Trusted Operating
•4
System
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


•5
System
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


•6
System
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


•7
System
Lattice Model
Upper bound

Lower bound

•CS 450/650 Lecture 21: Trusted Operating


•8
System
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


•9
System
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


•10
System
Illustration
High
o5
Write
Write
s2 o4
Read
Read o5 Object

o3
Write s2 Subject
Write
s1 o2
Read
Read

o1 Low

•CS 450/650 Lecture 21: Trusted Operating


•11
System
Harrison, Ruzzo, and Ullman Model
S1 S2 S3 O1 O2 O3

S1 control Owner
read
S2 control Owner read Owner
Read execute
write
S3 control read read execute

• Command
– Conditions and primitive operations
•CS 450/650 Lecture 21: Trusted Operating
•12
System
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


•13
System
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
•14
System
Take Grant Model (Cont.)

S2
read
O2

execute
read Read, write
O1
O3
S1
read

execute
S3

•CS 450/650 Lecture 21: Trusted Operating


•15
System
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
•16
System
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
•17
System
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
•18
System
OS Functions

•CS 450/650 Lecture 21: Trusted Operating


•19
System
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
•20
System
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


•21
System
Trusted OS Functions

•CS 450/650 Lecture 21: Trusted Operating


•22
System
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
•23
System
Kernel
• OS part that performs lowest level functions
User tasks

OS

OS Kernel

Hardware

•CS 450/650 Lecture 22: Trusted Operating


•24
System
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 22: Trusted Operating
•25
System
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 22: Trusted Operating
•26
System
Reference Monitor
• portion of a security kernel that controls accesses
to objects
• Collection of access controls for
– Devices, Files, Memory, Interprocess communication,
O O O
Other objects
Gate
• It must be S S S
– Always invoked when any object is accessed
– Small enough
• analysis, testing
– Tamperproof
•CS 450/650 Lecture 22: Trusted Operating
•27
System
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 22: Trusted Operating


•28
System
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 22: Trusted Operating


•29
System
TCB and Non-TCB Code
Applications

Utilities
Non-TCB
User request interpreter

Segmentation, paging, memory management
Primitive I/O
Basic Operations
Clocks, timing TCB
Interrupt handling
Hardware:registers memory
Capabilities
•CS 450/650 Lecture 22: Trusted Operating
•30
System
TCB monitors basic interactions
• Process activation

• Execution domain switching

• Memory Protection

• I/O operation

•CS 450/650 Lecture 22: Trusted Operating


•31
System
Combined Security Kernel / OS System

OS Kernel:
User tasks
- HW interactions
- Access control OS

OS Kernel

Hardware

OS:
- Resource allocation
- Sharing
- Access control
Security activity
- Authentication functions
•CS 450/650 Lecture 22: Trusted Operating
•32
System
Separate Security Kernel
Security Kernel:
User tasks
-Access control
-Authentication functions OS

Security Kernel

Hardware

OS:
- Resource allocation
- Sharing
- Hardware interactions
•CS 450/650 Lecture 22: Trusted Operating
•33
System
Separation
• Physical Separation

• Temporal Separation

• Cryptographic Separation

• Logical separation (isolation)

•CS 450/650 Lecture 22: Trusted Operating


•34
System
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 22: Trusted Operating


•35
System
Virtual machine

Virtual Virtual Virtual


Machine Machine Machine

User 1 User 2 User 3

Real OS

Real System Resources

•CS 450/650 Lecture 22: Trusted Operating


•36
System
IBM MVS/ESA
• Virtualization is used to provide logical
separation that gives the user the impression
of physical separation
– Each user feels that he/she has a separate
machine

• Paging System
– Each user’s virtual memory space can be as large
as the total addressable space

•CS 450/650 Lecture 22: Trusted Operating


•37
System
Layered OS
User processes

Compilers, database

OS Utility functions

File system, device allocation

Scheduling, sharing, MM

Synchronization, allocation
OS kernel
Security kernel Security functions

Hardware

•CS 450/650 Lecture 22: Trusted Operating


•38
System
Modules operating in Different Layers

Least trusted code

Most
trusted code
Data update

Data comparison

User ID lookup

User interface
User Authentication module
•CS 450/650 Lecture 22: Trusted Operating
•39
System
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 22: Trusted Operating


•40
System
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 22: Trusted Operating


•41
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

•CS 450/650 Lecture 22: Trusted Operating


•42
System
Example: find minimum
Entry

min  A[1]
i1

ii+1

yes
i>n Exit

no
yes
min < A[i]
no

min  A[i]

•CS 450/650 Lecture 22: Trusted Operating


•43
System
Finding the minimum value
Assertions
P: n > 0 Q: n > 0 and
1  i  n and
min  A[1]

R: n > 0 and S: n > 0 and


1  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]
•CS 450/650 Lecture 22: Trusted Operating
•44
System
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 22: Trusted Operating


•45
System
Evaluation
• Review: requirements, design, implementation,
assurance
• US “Orange Book” Evaluation
– Trusted Computer System Evaluation Criteria (TCSEC)
• European ITSEC Evaluation
– Information Technology Security Evaluation Criteria
• US Combined Federal Criteria
– 1992 jointly buy NIST and NSA

•CS 450/650 Lecture 22: Trusted Operating


•46
System

Vous aimerez peut-être aussi