Designing Trusted Operating Systems

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


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


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


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


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.


6/33


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


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


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/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


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


10/33


Lattice Mo e o Access Security Cont

The largest element of the lattice is the classification

The smallest element is

19


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


11/33


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


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


12/33



The implications of these two properties are shown in Figure 5-7.

23

24


13/33



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


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


14/33


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


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


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


16/33


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


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


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


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


19/33


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


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


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


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


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


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


24/33

47

48


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


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


27/33

Virtualization (Contd)

Virtua Mac ines

53

Layered Design

54

Layered Operating System.


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


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


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


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


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


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

Designing Trusted Operating Systems

Documents

Transcript of Designing Trusted Operating Systems