designing trusted operating systems
TRANSCRIPT
-
8/10/2019 Designing Trusted Operating Systems
1/33
Cha ter 5
Designing Trusted Operating Systems
ar es . eeger ar awrence eeger, ecur ty n omput ng,
4th Ed., Pearson Education, 20071
An operating system is trusted if we have confidence that it provides
t ese our serv ces cons stent y an e ect ve y Policy- every system can be described by its requirements:
statements o w at t e system s ou o an ow t s ou o t.
Model - designers must be confident that the proposed system will
meet ts requ rements w e protect ng appropr ate o ects an
relationships.
2
-
8/10/2019 Designing Trusted Operating Systems
2/33
Design - designers choose a means to implement it.
Trust- trust in t e system is roote in two aspects:
FEATURES- the operating system has all the necessary functionality needed
.
ASSURANCE- the operating system has been implemented in such a way that
we have confidence it will enforce the security policy correctly and
effectively.
3
5.1. What Is a Trusted S stem?
Software is trusted software if we know that the code has been
r gorous y eve ope an ana yze , g v ng us reason to trust t at t ecode does what it is expected to do and nothing more.
erta n ey c aracter st cs:
Functional correctness.
n orcement o ntegr ty.
Limited privilege:
ppropr ate con ence eve .
4
-
8/10/2019 Designing Trusted Operating Systems
3/33
Security professionals prefer to speak oftrustedinsteado secure operating systems.
Secure reflects a dichotomy: Something is either secure or not
secure.
Trust is not a dichotomy; degrees of trust
5
Secure Trusted
Eitheror:Somethingeitherisorisnotsecure.
Graded:Therearedegreesof"trustworthiness."
Propertyof presenter Property of receiver
characteristics
analysis
Absolute:notqualifiedastoRelative:viewedincontextof
owuse ,w ere,w en,or y
whom
use
A oal characteristic
6
-
8/10/2019 Designing Trusted Operating Systems
4/33
5.2. Securit Policies
A security policy is a statement of the security we expect the systemto en orce.
Military Security Policy
ase on protect ng c ass e n ormat on.
Each piece of information is ranked at a particular sensitivity level,
suc as unc ass e , restr cte , con ent a ,secret, or top secret.
The ranks or levels form a hierarchy, and they reflect an increasing
or er o sens t v ty
7
8
-
8/10/2019 Designing Trusted Operating Systems
5/33
Military Security Policy (Contd)
In ormation access is imite
by the need-to-knowrule
ac p ece o c ass e
information may be
assoc ate w t one or more
projects,
ca e compartments,
describing the subject matter
o e n orma on.
9
Assign names to identify the compartments, such assnowshoe, crypto, andSweden
The combination is called the class or classification of a
10
piece of information.
-
8/10/2019 Designing Trusted Operating Systems
6/33
Military Security Policy (Contd)
Intro uce a re ation , ca e ominance, on t e sets o sensitive
objects and subjects. For a subjects and an object o,
We say that o dominatess (ors is dominated by o) ifs o; the
re at on s t e oppos te. om nance s use to m t t e sens t v ty
and content of information a subject can access.
11
Military Security Policy (Contd)
su ect can rea an o ect on y the clearance level of the subject is at least as high as that of the
the subject has a need to know about all compartments for which the
information is classified
These conditions are equivalent to saying that the subject dominates the
object.
12
-
8/10/2019 Designing Trusted Operating Systems
7/33
Commercial Security Policies
Data items at any eve may ave i erent egrees o sensitivity,
such aspublic,proprietary, or internal; here, the names may vary
among organ zat ons, an no un versa erarc y app es.
Projects and departments tend to be fairly well separated, with
some over ap as peop e wor on two or more pro ects.
Corporate-level responsibilities tend to overlie projects and
epartments, as peop e t roug out t e corporat on may nee
accounting or personnel data.
13
Commercial View of Sensitive Information.
14
-
8/10/2019 Designing Trusted Operating Systems
8/33
Commercial Security Policies
Two signi icant i erences exist etween commercia an mi itary
information security.
rs , ou s e e m ary, ere s usua y no orma ze no on o
clearances.
Second because there is no formal conce t of a clearance the rules for
allowing access are less regularized.
15
5.3. Models of Securit
Multilevel Security
ant to u a mo e to represent a range o sens t v t es an toreflect the need to separate subjects rigorously from objects to
w c t ey s ou not ave access.
The generalized model is called the lattice model of security.
16
-
8/10/2019 Designing Trusted Operating Systems
9/33
What Is a Lattice?
A attice is a mat ematica structure
of elements organized by a relation
among t em, represente y
a relational operator.
17
Sample Lattice.
Multilevel Security (Contd)
att ce o e o ccess ecur ty The military security model is representative of a more general scheme,
.
The dominance relation defined in the military model is the relation for
the lattice.
The relation is transitive and antisymmetric.
Transitive: Ifa b and b c, then a c
Antisymmetric: Ifa b and b a, then a = b
18
-
8/10/2019 Designing Trusted Operating Systems
10/33
Multilevel Security (Contd)
Lattice Mo e o Access Security Cont
The largest element of the lattice is the classification
The smallest element is
19
Multilevel Security (Contd)
e a a u a on ent a ty o e A formal description of the allowable paths of information flow in a secure
.
The model's goal is to identify allowable communication when maintaining
secrecy is important.
The model has been used to define security requirements for systems
concurrently handling data at different sensitivity levels.
We are interested in secure information flows because they describe
acceptable connections between subjects and objects of different levels of
.
20
-
8/10/2019 Designing Trusted Operating Systems
11/33
Multilevel Security (Contd)
Be La Pa u a Con i entia ity Mo e Cont
Consider a security system with the following properties.
.
Each subjects inS and each object o in Ohas a fixed security class C(s)
and C(o) (denoting clearance and classification level).
The security classes are ordered by a relation .
21
Multilevel Security (Contd)
e a a u a on ent a ty o e ont Two properties characterize the secure flow of information.
.
object o only ifC(o) C(s).
*-Property (called the "star property"). A subjects who has readaccess to
an object o may have write access to an objectp only ifC(o) C(p).
The *-property preventswrite-down, which occurs when a subject with
access to high-level data transfers that data by writing it to a low-level
.
22
-
8/10/2019 Designing Trusted Operating Systems
12/33
Multilevel Security (Contd)
Be La Pa u a Con i entia ity Mo e Cont
The implications of these two properties are shown in Figure 5-7.
23
24
-
8/10/2019 Designing Trusted Operating Systems
13/33
Multilevel Security (Contd)
Be La Pa u a Con i entia ity Mo e Cont
The classifications of subjects (represented by squares) and objects
As the classification of an item increases, it is shown higher in the figure.
The flow of information is generally horizontal (to and from the same level)
and upward (from lower levels to higher).
A downward flow is acceptable only if the highly cleared subject does not
pass any high-sensitivity data to the lower-sensitivity object.
25
Multilevel Security (Contd)
e a a u a on ent a ty o e ont For computing systems, downward flow of information is difficult because a
information and having read a piece of information that influenced what was
later written.
26
-
8/10/2019 Designing Trusted Operating Systems
14/33
Multilevel Security (Contd)
Bi a Integrity Mo e
The Biba model is the counterpart (sometimes called the dual) of the
.
Biba defines "integrity levels," which are analogous to the sensitivity
levels of the BellLa Padula model.
Subjects and objects are ordered by an integrity classification scheme,
denoted I(s) and I(o).
27
Multilevel Security (Contd)
a ntegr ty o e ont The properties are
Simple Integrity Property.
Subjects can modify (have write access to) object o only ifI(s) I(o)
Integrity *-Property. If subjects has readaccess to object o with integrity
level I(o),s can have write access to object only ifI(o) I( )
28
-
8/10/2019 Designing Trusted Operating Systems
15/33
5.4. Trusted O eratin S stem Desi n
Trusted System Design Elements
Security consi erations perva e t e esign an structure o
operating systems implies two things.
rs , an opera ng sys em con ro s e n erac on e ween su ec s an
objects, so security must be considered in every aspect of its design.
Second because securit a ears in ever art of an o eratin s stem its
design and implementation cannot be left fuzzy or vague until the rest of
the system is working and being tested.
29
Trusted System Design Elements (Contd)
evera mportant es gn pr nc p es are qu te part cu ar to secur tyand essential for building a solid, trusted operating system.
eas pr v ege. ac user an eac program s ou opera e y us ng e
fewest privileges possible.
Econom o mechanism.The desi n of the rotection s stem should be
small, simple, and straightforward. Such a protection system can be carefully
analyzed, exhaustively tested, perhaps verified, and relied on.
Open design. An open design is available for extensive public scrutiny,
thereby providing independent confirmation of the design security.
30
-
8/10/2019 Designing Trusted Operating Systems
16/33
Trusted System Design Elements (Contd)
Severa important esign princip es are quite particu ar to security
and essential for building a solid, trusted operating system. (Contd)
omp e e me a on. very access a emp mus e c ec e . o rec
access attempts (requests) and attempts to circumvent the access checking
mechanism should be considered and the mechanism should be ositioned
so that it cannot be circumvented.
Permission based.The default condition should be denial of access. Aconservative designer identifies the items thatshouldbe accessible, rather
than those that should not.
31
Trusted System Design Elements (Contd)
evera mportant es gn pr nc p es are qu te part cu ar to secur tyand essential for building a solid, trusted operating system. (Contd)
epara on o pr v ege. ea y, access o o ec s s ou epen on more
than one condition, such as user authentication plus a cryptographic key. In
this wa someone who defeats one rotection s stem will not have
complete access.
Least common mechanism. Shared objects provide potential channels for
information flow. Systems employing physical or logical separation reduce
the risk from sharing.
. y u , u y
avoided.32
-
8/10/2019 Designing Trusted Operating Systems
17/33
Security Features of Ordinary Operating Systems
33
Security Features of Ordinary Operating Systems (Contd)
ser aut ent cat on.Memory protection.
e an ev ce access contro .
Allocation and access control to general objects.
n orce s ar ng.
Guaranteed fair service.
nterprocess commun cat on an sync ron zat on.
Protected operating system protection data.
34
-
8/10/2019 Designing Trusted Operating Systems
18/33
Security Features of Trusted Operating Systems
35
Security Features of Trusted Operating Systems (Contd)
ent cat on an ut ent cat on Trusted operating systems require secure identification of individuals, and
.
Mandatory and Discretionary Access Control
Mandator access control (MAC) means that access control olic
decisions are made beyond the control of the individual owner of an
object.
Discretionary access control (DAC) leaves a certain amount of access
control to the discretion of the object's owner or to anyone else who is
'u z .
36
-
8/10/2019 Designing Trusted Operating Systems
19/33
Security Features of Trusted Operating Systems (Contd)
O ject Reuse Protection
To prevent object reuse leakage, operating systems clear (that is, overwrite)
.
Complete Mediation
All accesses must be controlled.
Trusted Path
Want an unmistakable communication, called a trusted path, to ensure thatthey are supplying protected information only to a legitimate receiver.
37
Security Features of Trusted Operating Systems (Contd)
ccounta ty an u t Accountability usually entails maintaining a log of security-relevant events
,
addition, deletion, or change. Thisaudit log must obviously be protected
from outsiders, and every security-relevant event must be recorded.
Audit Log Reduction
Intrusion Detection
Intrusion detection software builds patterns of normal system usage,
triggering an alarm any time the usage seems abnormal.
38
-
8/10/2019 Designing Trusted Operating Systems
20/33
Kernelized Design
A security erne is responsi e or en orcing t e security
mechanisms of the entire operating system.
e secur ty erne prov es t e secur ty nter aces among t e
hardware, operating system, and other parts of the computing
system.
Typically, the operating system is designed so that the security
erne s conta ne w t n t e operat ng system erne .
39
Kernelized Design (Contd)
evera goo es gn reasons w y secur ty unct ons may e so atein a security kernel.
overage. very access o a pro ec e o ec mus pass roug e
security kernel.
Se aration. Isolatin securit mechanisms both from the rest of the
operating system and from the user space makes it easier to protect those
mechanisms from penetration by the operating system or the users.
Unity. All security functions are performed by a single set of code, so it is
easier to trace the cause of any problems that arise with these functions.
40
-
8/10/2019 Designing Trusted Operating Systems
21/33
Kernelized Design (Contd)
Severa goo esign reasons w y security unctions may e iso ate
in a security kernel.
o a y. anges o e secur y mec an sms are eas er o ma e an
easier to test.
Com actness. Because it erforms onl securit functions the securit
kernel is likely to be relatively small.
Verifiability. Being relatively small, the security kernel can be analyzedrigorously. For example, formal methods can be used to ensure that all
security situations (such as states and state changes) have been covered by
.
41
Reference Monitor
42
-
8/10/2019 Designing Trusted Operating Systems
22/33
Reference Monitorn (Contd)
Must e
Tamperproof, that is, impossible to weaken or disable
, ,
Analyzable, that is, small enough to be subjected to analysis and testing,
the completeness of which can be ensured
43
Trusted Computing Base (TCB)
e truste comput ng ase, or , s t e name we g ve toeverything in the trusted operating system necessary to enforce the
secur ty po cy.
44
-
8/10/2019 Designing Trusted Operating Systems
23/33
45
Trusted Computing Base (Contd)
e , w c must ma nta n t e secrecy an ntegr ty o eacdomain, monitors four basic interactions.
rocess ac va on.
Execution domain switching. Processes running in one domain often invoke
rocesses in other domains to obtain more sensitive data or services.
Memory protection. Because each domain includes code and data stored in
memory, the TCB must monitor memory references to ensure secrecy and
integrity for each domain.
I/O operation.
46
-
8/10/2019 Designing Trusted Operating Systems
24/33
47
48
-
8/10/2019 Designing Trusted Operating Systems
25/33
Separation/Isolation
p ysica separation, two i erent processes use two i erent
hardware facilities.
empora separat on occurs w en erent processes are run at
different times.
ncrypt on s use or cryptograp c separat on
Logical separation, also called isolation, is provided when a
process suc as a re erence mon tor separates one user s o ects
from those of another user.
49
50
-
8/10/2019 Designing Trusted Operating Systems
26/33
Virtualization
T e operating system emu ates or simu ates a co ection o a
computer system's resources.
v rtua mac ne s a co ect on o rea or s mu ate ar ware
facilities
51
Virtualization (Contd)
u t p e rtua emory paces
52
-
8/10/2019 Designing Trusted Operating Systems
27/33
Virtualization (Contd)
Virtua Mac ines
53
Layered Design
54
Layered Operating System.
-
8/10/2019 Designing Trusted Operating Systems
28/33
Layered Design
55
5.5. Assurance in Trusted O eratin S stems
Typical Operating System Flaws
nown u nera t es User interaction is the largest single source of operating system
An ambiguity in access policy.
On one hand, we want to separate users and protect their individual
resources.
On the other hand, users depend on shared access to libraries, utility
programs, common data, and system tables.
Incomplete mediation
,
operating systems for large computing systems.
56
-
8/10/2019 Designing Trusted Operating Systems
29/33
Assurance Methods Testing
Testing is the most widely accepted assurance technique.
, ,
following reasons:
Testing can demonstrate the existence of a problem, but passing tests
does not demonstrate the absence of problems.
Testing adequately within reasonable time or effort is difficult because
the combinatorial explosion of inputs and internal states makes testing
very complex.
57
Assurance Methods
est ng Testing is the most widely accepted assurance technique.
, ,
following reasons: (Contd)
Testing based only on observable effects, not on the internal structure of
a product, does not ensure any degree of completeness.
Testing based on the internal structure of a product involves modifying
the product by adding code to extract and display internal states. That
extra functionality affects the product's behavior and can itself be a
.
58
-
8/10/2019 Designing Trusted Operating Systems
30/33
Assurance Methods
Penetration Testing
A testing strategy often used in computer security is called penetration
, , .
A team of experts in the use and design of operating systems tries to crack
the system being tested.
59
Assurance Methods
orma er cat on The most rigorous method of analyzing security is through formal verification
Time.The methods of formal verification are time consuming to perform.
Stating the assertions at each step and verifying the logical flow of the
assertions are both slow processes.
Complexity. Formal verification is a complex process. For some systems
with large numbers of states and transitions, it is hopeless to try to state
and verify the assertions. This situation is especially true for systems that
.
60
-
8/10/2019 Designing Trusted Operating Systems
31/33
61
Assurance Methods
a at on Validation is the counterpart to verification, assuring that the system
.
Validation makes sure that the developer is building the right product
(according to the specification)
Verification checks the quality of the implementation
Several different ways to validate an operating system
Requirements checking.
Design and code reviews.
.
62
-
8/10/2019 Designing Trusted Operating Systems
32/33
Evaluation
U.S. Orange Boo Eva uation
In the late 1970s, the U.S. Department of Defense (DoD) defined a set of
, .
Published in a document [DOD85] that has become known informally as the
"Orange Book," the Trusted Computer System Evaluation Criteria (TCSEC)
provides the criteria for an independent evaluation
63
Evaluation
. . range oo va uat on ont The levels of trust are described as four divisions, A, B, C, and D, where A has
.
Within a division, additional distinctions are denoted with numbers; the
higher numbers indicate tighter security requirements. Thus, the complete
set of ratings ranging from lowest to highest assurance is D, C1, C2, B1, B2,
B3, and A1.
64
-
8/10/2019 Designing Trusted Operating Systems
33/33
Evaluation
U.S. Orange Boo Eva uation Cont
Class D: Minimal Protection
Class C2: Controlled Access Protection
Class B1: Labeled Security Protection
Class B2: Structured Protection
Class B3: Security Domains
Class A1: Verified Design
65
5.6. Summar of Securit in O eratin S stems
Developing secure operating systems involves four activities.
e env ronment to e protecte must e we un erstoo . Policy statements and models
e essent a components o systems are ent e
The interactions among components can be studied.
system to mp ement t must e es gne to prov e t e es re
protection.
ssurance t at t e es gn an ts mp ementat on are correct