Designing Trusted Operating Systems Operating Systems

Download Report

Transcript Designing Trusted Operating Systems Operating Systems

Chapter 5 – Designing Trusted
Operating Systems



What makes an operating system
“secure”? Or “trustworthy?
How are trusted systems designed, and
which of those design principles carry over
naturally to other program development
tasks?
How do we develop “assurance” of the
correctness of a trusted operating
systems?
Designing Trusted Operating
Systems

Primitive security services
• Memory protection
• File protection
• General object access control
• User authentication

OS is trusted if we have confidence
that it provides these four services in
a consistent and effective way.
What is a trusted system?
Secure
Trusted
Either-or: something
either is or is not secure
Graded: There are
degrees of
“trustworthiness
Property of presenter
Property of receiver
Asserted based on
product characteristics
Judged based on
evidence and analysis
Absolute: not qualified as Relative: viewed in
to how, where, when, or context of use
by whom used
A goal
A characteristic
What is a trusted system?





Trusted process – process that can affect system
security
Trusted product – evaluated and approved
product
Trusted software- software portion of system that
can be relied upon to enforce security policy
Trusted computing base – set of all protection
mechanisms within a computing system that
enforce a nified security policy
Trusted system – system that employs sufficient
hardware and software integrity measures to
allow its use for processing sensitive information
Security Policies
security policy – statement of
security we expect the system to
enforce
 Military Security Policy

• based on protecting classified
information
• Information access is limited by needto-know rule
• Each piece of classified info is
associated with a compartment
Military Security Policy



Class (classification) - <rank; compartment>
Clearance - indication that person is trusted to
access info up to a certain level of sensitivity
Dominance –




s <= O iff ranks <= ranko
and compartmentss <= compartmentso
Clearance level of subject is at least as high as
that of the information
Subject has a need to know about all
compartments for which the information is
classified.
Commercial Security Policies
Data items at any level may have
different degrees of sensitivity
(public, proprietary, internal)
 No formalized notion of clearances
 No dominance function for most
commercial information access

Clark-Wilson Commercial Security Policy

Well-formed transactions –
perform
steps in order, exactly as listed & authenticating
the individuals who perform the steps
Goal – maintain consistency
between internal data and external
expectations of the data
 Process constrained data items by
transformation procedures

• <userID, TPi, {CDIj, CDIk, …}>
Commercial Security Policy
Separation of duty – division of
responsibilities (manual system)
 Chinese Wall Security Policy –

• Confidentiality Policy
• Objects (e.g. files)
• Company Groups (all objects
concerning a particular company)
• Conflict classes (cluster competing
companies)
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 its requirements
Multilevel Security


Want to build a model to represent a
range of sensitivities and to reflect need to
separate subjects from objects to which
they should not have access.
Use the lattice model of security
• military security model where <= in the model
is the relation operator in the lattice
(transitive, antisymmetric)
• Commercial security model (public,
proprietary, internal)
Bell-La Padula Confidentiality Model

Formal description of allowable paths of
information flow in a secure system
• Simple Security Property. A subject s may
have read access to an object o only if C(o)
<= C(s)
• *-Property – 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)

The *-property is used to prevent write-down
(subject with access to high-level data transfers that
data by writing it to a low-level object.
Bibb Integrity Model
Simple Integrity Property. Subject
s can modify (have write access to)
object o only if I(s) >= I(o)
 Integrity *-Property. If subject s
has read access to object o with
integrity level I(o), s can have write
access to object p only if I(o) >=
I(p)

Models Proving Theoretical
Limitations of Security Systems


Graham-Denning Model – introduced
concept of a formal system of protection
rules; constructs a model having generic
protection properties
Harrison-Ruzzo-Ullman Model – uses
commands involving conditions and
primitive operations where a protection
system is a set of subjects, objects,
rights, and commands
Take-Grant Systems

Four operations performed by
subjects on objects with rights
• Create(o,r) subject creates an object
with certain rights
• Revoke(o,r) subject removes rights from
object
• Grant(o,p,r) subject grants to o access
rights on p
• Take (o,p,r) subject removes from o
access rights on p
Trusted System Design Elements
Least privilege
 Economy of mechanism
 Open design
 Complete mediation
 Permission based
 Separation of privilege
 Least common mechanism
 Ease of use

Security Features of Ordinary
Operating Systems








Authentication of users
Protection of memory
File and I/O device access control
Allocation and access control to general
objects
Enforcement of sharing
Guarantee of fair service
Interprocess communications and
synchronization
Protection of operating system protection
data
Security Features of Trusted
Operating Systems



Trusted systems incorporate technology to
address both features and assurance
Objects are accompanied (surrounded) by
an access control mechanism
Memory is separated by user, and data
and program libraries have controlled
sharing and separation
Security Features of Trusted
Operating Systems

Identification and Authentication
• Require secure id of individuals, each
individual must be uniquely identified

Mandatory and Discretionary Access
Control
• MAC – access control policy decisions are
made beyond the control of the individual
owner of the object
• DAC – leaves access control to the discretion
of the object’s owner
• MAC has precedence over DAC
Security Features of Trusted
Operating Systems

Object Reuse Protection
• Prevent object reuse leakage
• OS clears (overwrites) all space to be
reassigned
• Problem of magnetic remanence

Complete Mediation
• All accesses must be controled

Trusted Path
• For critical operations (setting password, etc.),
users want unmistakable communications
Security Features of Trusted
Operating Systems

Accountability and Audit
• Maintain a log of security relevant events
• Audit log must be protected from outsiders

Audit Log Reduction
• Audit only open and close of files/objects

Intrusion detection
• Build patterns of normal system usage,
triggering an alarm any time usage seems
abnormal
• Intrusion prevention
Kernelized Design

Kernel – part of OS that performs
lowest-level functions
• Synchronization, interprocess
communications, message passing,
interrupt handling
• Security kernel – responsible for
enforcing security mechanism for entire
OS; provides interface among the
hardware, OS, and other parts of
computer system