Computer security principles and practice 3rd by williams stallings and brown ch13

Chapter 13
Trusted Computing and Multilevel Security


Computer Security Models

•
•

Problems involved both
design and
implementation
Led to development of
formal security models

o

All complex software systems have eventually

All complex software systems have eventually
Two
fundamental computer
revealed flaws or bugs that need to be fixed

security facts:
It is extraordinarily difficult to build computer
hardware/software not vulnerable to security
attacks

•

Initially funded by US
Department of Defense

Bell-LaPadula (BLP) model
very influential


Bell-LaPadula (BLP) Model
•
•
•
•
•
•

Developed in 1970s
Formal model for access control
Subjects and objects are assigned a security class

o
o

Top secret > secret > confidential > restricted > unclassified
Form a hierarchy and are referred to as security levels

A subject has a security clearance
An object has a security classification
Security classes control the manner by which a subject may access an object

Bell-LaPadula (BLP) Model
Access Modes

The subject is
READ
READ

allowed only

APPEND
APPEND

read access
to the object

is allowed
only write
access to
the object

The subject is

The subject

The subject

allowed neither

is allowed

WRITE
WRITE

both read

EXECUTE
EXECUTE

read nor write

and write

access to the

access to the

object but may

object

invoke the
object for

•

execution

Multilevel security

o

o

No read up

•
•

Subject can only read an object of less or equal security level
Referred to as the simple security property (ss-property)

No write down

•
•

A subject can only write into an object of greater or equal security level
Referred to as the *-property


high-level object-1

flow of
information

malicious subject
with high-level
security clearance
low-level object-1

Figure13.1 Information Flow ShowingtheNeed for the*-property

BLP Formal Description
•
•

Based on current state of system (b, M, f, H):
(current access set b, access matrix M, level function f, hierarchy H)

Three BLP properties:
ss-property: (Si, Oj, read) has fc(Si) ≥ fo(Oj).
*-property: (Si, Oj, append) has fc(Si) ≤ fo(Oj) and
(Si, Oj, write) has fc(Si) = fo(Oj)

•

ds-property: (Si, Oj, Ax) implies Ax ∈ M[Si

BLP give formal theorems
o Theoretically possible to prove system is secure
o In practice usually not possible


Release access

•

Change object level

•

Change current level

•

Give access permission

•

Rescind access permission

•

Create an object

•

Delete a group of objects

•

8

7

6

5

4

3

2

1

BLP Rules


Carla

level roles

c1-s

operation
roles
c1-s— read

c1-t

c1-s— write

c1-t — write

f2

c1-t — read

f1

(a) Two newfiles arecreated: f1: c1-t; f2: c1-s

Carla

level roles

operation
roles
c1-s— read

f3
(comments to f2)

Dirk

c1-s

c1-t

c1-s— write

c1-t — write

f2

c1-t — read

f1

(b) A third fileisadded: f3: c1-s

Figure13.2 Exampleof Useof BLP Concepts (page 1 of 3)


Carla

level roles

Dirk

c1-s

operation
roles
c1-s— read

c1-t

c1-s — write

f3 (comments
to f2)

f2

c1-t — write

f4

exam

c1-t — read

exam
template

f1

(c) An exam is created based on an existingtemplate: f4: c1-t

Carla

level roles

operation
roles
c1-s— read

f3 (comments
to f2)

Dirk

c1-s

c1-t

c1-s — write

f2

c1-t — write

f4
exam

f1

c1-t — read

exam
template

(d) Carla, as student, ispermitted acess to theexam: f4: c1-s

Figure13.2 Exampleof Useof BLP Concepts (page 2 of 3)


Carla

Dirk

level roles

operation
roles
c1-s — read

f3 (comments

to f2)

c1-s

c1-t

c1-s — write

f2

c1-t — write

f4
exam

f1

c1-t — read

f5 (exam
answer)

exam
template

(e) Theanswersgiven by Carla areonly accessiblefor theteacher: f5: c1-t

Figure13.2 Exampleof Useof BLP Concepts (page 3 of 3)

root

descriptor segment
current-process

DSBR

segment ptr

process level table

r

parent

e w

segment ACL L s
current-process L u
ACL

Ls = segment security level
Lu = user security level

segment

Figure13.3 Multics Data Structures for MLS

current-process r e w

Limitations to the BLP Model
•

Incompatibility of confidentiality and integrity within a single MLS system

o
o

MLS can work either for powers or for secrets but not readily for both
This mutual exclusion excludes some interesting power and integrity centered technologies from being used effectively in
BLP style MLS environments

•

Cooperating conspirator problem in the presence of covert channels

o
o

In the presence of shared resources the *-property may become unenforceable
In essence, the BLP model effectively breaks down when (untrusted) low classified executable data are allowed to be
executed by a high clearance (trusted) subject


Biba Integrity Model
•
•

Various models dealing with integrity

Strict integrity policy:

o
o
o

Simple integrity:

I(S) ≥ I(O)

Integrity confinement: I(S) ≤ I(O)
Invocation property:

I(S1) ≥ I(S2)

write

High-integrity process

read

write

Low-integrity process

read

High-integrity file

Low-integrity file

disallowed

Figure13.4 Contamination With SimpleIntegrity Controls [GASS88]


USERS
CDI = constrained data item
IVP = integrity verification procedure
TP = transformation procedure
UDI = unconstrained data item

E3: Users areauthenticated

E2: Users authenticated for TP
C3: Suitableseparation of duty

C1: IVP validates CDI state
C5: TPs validateUDI

C2: TPs preservevalid state

CDI

IVP

CDI
log
CDI

System in

somestate

UDI

CDI

TP

E4: Authorization
lists changed only
by security officer

CDI
log
CDI

C4: TPs writeto log
E1: CDIs changed only by authorized TP

Figure13.5 Summary of Clark-Wilson System Integrity Rules [CLAR87]


Set of all objects

Conflict of
interest classes

CI 1

Company

datasets Bank A
Individual
objects

a

b

CI 2

Bank B
c

d

e

CI 3

GasA

Oil A

f

g

Oil B
h

i

(a) Exampleset

Set of all objects

CI 1

Bank A
g

b

CI 2

Bank B
c

Set of all objects

d

e

CI 3

GasA

Oil A

f

g

CI 1

Oil B
h

(b) J ohn has accessto Bank A and Oil A

i

Bank A
g

b

CI 2

Bank B
c

d

e

CI 3

GasA

Oil A

f

g

Oil B
h

(c) J anehasaccessto Bank A and Oil B

Figure13.6 Potential Flow of Information Between Two CIs

i


Table
13.1

Terminology
Related
to
Trust


Audit
file

Subjects

Reference
Monitor
(policy)

Security kernel
database
Subject: security
clearance
Object: security
classification

Figure13.7 ReferenceMonitor Concept

Objects


Bob

Bob: RW

Reference
Monitor

Bob

Bob: RW

"CPE170KS"
Program

"CPE170KS"
Program

Data file

Alice: RW
Bob: W

Alice

Program

Alice: RW
Bob: W

Alice

Back-pocket
file

Back-pocket
file

Program

(a)

Bob

Data file

(c)

Bob: RW

Reference
Monitor

Bob

Bob: RW

"CPE170KS"
Program

"CPE170KS"
Program

Data file

Alice: RW
Bob: W

Alice

Program

Back-pocket
file

(b)

Data file

Alice: RW
Bob: W

Alice
Back-pocket
file

Program

(d)

Figure13.8 Trojan Horseand SecureOperatingSystem


Multilevel Security (MLS)
RFC 4949 defines multilevel security as follows:
“A mode of system operation wherein (a) two or more
security levels of information are allowed to be handled concurrently within the same
system when some users having access to the system have neither a security clearance
nor need-to-know for some of the data handled by the system and (b) separation of the
users and the classified material on the basis, respectively, of clearance and classification
level are dependent on operating system control.”


Table

13.2

RBAC
Elements


Department Table- U

Employee- R

Did

Name

Mgr

Name

Did

Salary

Eid

4

accts

Cathy

Andy

4

43K

2345

8

PR

James

Calvin

4

35K

5088

Cathy

4

48K

7712

James

8

55K

9664

Ziggy

8

67K

3054

(a) Classified by table

Department Table

Employee

Did -U

Name -U

Mgr -R

Name -U

Did -U

Salary -R

Eid -U

4

accts

Cathy

Andy

4

43K

2345

8

PR

James

Calvin

4

35K

5088

Cathy

4

48K

7712

James

8

55K

9664

Ziggy

8

67K

3054

(b) Classified by column (attribute)

Figure
13.9 Approaches to DatabaseClassification (page 1 of 2)
Figure
13.10


Department Table
Did

Name

Mgr

4

accts

Cathy

8

PR

James

Employee
Name

Did

Salary

Eid

R

Andy

4

43K

2345

U

U

Calvin

4

35K

5088

U

Cathy

4

48K

7712

U

James

8

55K

9664

R

Ziggy

8

67K

3054

R

(c) Classified by row (tuple)

Department Table
Did
4-U
8-U

Name

Mgr

accts - U Cathy - R
PR - U

James -R

Employee
Name

Did

Salary

Eid

Andy - U

4-U

43K - U

2345 - U

Calvin - U

4-U

35K - U

5088 - U

Cathy - U

4-U

48K - U

7712 - U

James - U

8-U

55K - R

9664 - U

Ziggy - U

8-U

67K - R

3054 - U

(d) Classified by element

Figure
13.10
Approaches to DatabaseClassification (page 2 of 2)
Figure
13.9


Database Security
Read Access

•
•
•
•
•

DBMS enforces simple security rule (no read up)
Easy if granularity is entire database or at table level
Inference problems if have column granularity

o
o

If can query on restricted data can infer its existence

•

SELECT Ename FROM Employee WHERE Salary > 50K

Solution is to check access to all query data

Also have problems if have row granularity

o

Null response indicates restricted/empty result

No extra concerns if have element granularity


Database Security
Write Access

•
•
•
•

Enforce *-security rule (no write down)
Have problem if a low clearance user wants to insert a row with a primary
key that already exists in a higher level row:

o
o
o

Can reject, but user knows row exists
Can replace, compromises data integrity
Polyinstantiation and insert multiple rows with same key, creates conflicting entries

Same alternatives occur on update
Avoid problem if use database/table granularity