Confidentiality in a Replicated Architecture Trusted ... - CiteSeerX

Confidentiality in a Replicated Architecture Trusted Database System: 1

A Formal Model

Oliver Costich

John McLean John McDermott

Center for Secure Information Systems

Center for High Assurance

George Mason University

Computer Systems

4400 University Drive

Naval Research Laboratory

Fairfax, Virginia 22030

Washington, D.C. 20375

Abstract

The purpose of this paper is to demonstrate that the confidentiality (as opposed to integrity) component of a

Unlike previous approaches to developing a trusted database system, the replicated architecture approach

mechanisms

a model of the SINTRA replicated architecture trusted database system which shows how the logical (users')

structure

and

operations

of

enforced without

as

a

any

function

loss

of

of

the

database

to the database system itself, relying

solely on those in the the front end component, as described below.

view of the system and its security policy is translated physical

is

alone,

the replicated architecture without adding any trusted

through replication of data and operations. We present

the

policy

functionality. That is, confidentiality is obtained in

provides access control at a high level of assurance

into

security

architecture

the While it is not difficult to see that confidentiality is

SINTRA system. We formalize the intended security

enforced "free" in this system, there has been some

policy for replicated architecture and demonstrate that

confusion regarding the replicated architecture model

a high level of assurance can be obtained solely from

which we hope to resolve in this paper. To this end, we

replication with virtually no change to the structure of

will

the underlying database systems or the security kernel.

present

a

formal

security

policy

model

for

a

replicated architecture trusted database. From the model it will be apparent that the confidentiality (as

1. Introduction

opposed to integrity) component of security policy is enforced as a function of the architecture alone. That

The replicated architecture for trusted databases was

is, virtually no argument is necessary that the system

proposed in [5]. The underlying motivation for this

provides

approach was improved performance and the ability to

get

access

commercially

control

easily.

available

It

also

databases

can

appears be

that

used

has

developed

a

policy

is

not

so

view), and will be discussed as well.

We should note that the usefulness of the replicated

development time. The SINTRA project at The Naval Laboratory

Integrity

for

much of the system, providing economies of cost and

Research

confidentiality.

apparent (and may be arguable from some points of

architecture

prototype

approach

is

not

limited

to

database

systems, but can also be used in many other trusted

trusted database system based on this architecture.

system applications, and that the level of assurance of

1

Appears in Proceedings of the Computer Security Foundations Workshop VII, pages 60-65, IEEE

Computer Society, 1994.

60

the resulting system will be the same as that of the

but

front end component.

easily.

We

present

database

the

logical

followed

by

a

(user)

view

discussion

of

of

a

the

model

and

then

discuss

the

3.

application

of

this

architecture

to

The

The

trusted

SINTRA

Logical

View

of

security

features

more

Architecture

and

replicated

separate

architecture

backend

utilizes

database

for

a

each

security level in the security lattice. Each backend database

The

certain

SINTRA

physically

applications other than databases.

2.

obtain

Security Policy

ramifications.

Finally, we look at other modeling considerations, and the

to

trusted SINTRA

architecture. We proceed to the development of the formal

also

a

Trusted

can

be

thought

of

as

container

of

the

appropriate security level. In addition, access to the

Database

backend databases is mediated by a trusted front-end system (TFE).

The logical view of a system is the view of the system as it appears to the user. To the user, a database

The

consists of a collection of data items. They access these

identification functions, and also insures that a user

TFE

performs

the

usual

authorization

and

data items via transactions built as sequences of read

who is logged on at a particular security level has

and write operations on the data items. Operations

access to only the single backend database of the

inherit a security level from the log-on clearance of

corresponding security level. Other functions handled

the user on whose behalf they are being executed.

by

Data items have assigned security levels and these

separation of entities to obtain database functionality,

security levels form a lattice.

e.g., queues for concurrency control.

the

TFE

may

include

those

which

require

From this point of view, we would like to enforce a

Not all of the TFE need be trusted, but the trusted

security policy similar to the

portion must have a level of assurance at least as high

Bell-LaPadula criteria

as that required by the whole database. Thus for a

[1].

high assurance database, which is our concern here, 1) Simple Security Property: A read operation can

the trusted portion of the TFE (usually an operating

access a data item if and only if its security level

system) will have its own security policy model. The

dominates that of the data item.

issue for us then becomes what must be added to it to

2) Restricted

obtain a model for the rest of the database.

’-Property: A write operation can access

a data item if and only if its security level equals that

A data item of the logical database is represented in

of the data item.

the backend database by placing a replica of that data item in each backend database whose security level

Implicit in this criteria is that the subjects of the

dominates the logical security level of the data item.

logical system are the operations and the objects, data

In other words, if data item x has logical security level

items.

a, then a copy of x appears in every backend database

When databases are actually designed, multiple copies

data items, which, of course, now include all replicas

or

of

whose security level dominates a. Objects are these

replicas

of

data

items

are

frequently

used

to

the

logical

data

items.

These

replicas

will

be

improve performance by promoting concurrency of

referred to as physical data items to distinguish them

transaction execution. This creates the problem of

from the logical ones.

reconciling

the

logical,

single-copy

view

of

the Similarly, subjects of SINTRA are of two types. The

database with the physical view of the system which with copies because the management of the

first are the logical read and write operations of user-

copies is transparent to the users. In the case at hand,

submitted transactions, and their security level is

we will adopt replication of data items, which creates

determined

a similar situation, not only to improve performance

submitted them. Second, each logical write operation

deals

by

the

clearance

of

the

user

who

of a user submitted transaction must also be executed

61

at each higher security level backend database in

1) A read operation can access a data item if

order to maintain consistency in the values of the

and

replicas. The physical write operations which update

physical security level of the data item.

the

replicas

of

a

data

item

may

themselves

only

if

its

security

level

equals

the

be

considered as replicas of their underlying logical write

2) A write operation can access a data item if

operation. That is, if some transaction writes x at

and only if its physical security level equals

some security level, then all copies of x at higher

the physical security level of the data item

security levels must be written as well. Thus each

and its logical security level equals the logical

logical write operation generates many physical

security level of the data item.

operations. An implication of this is that operations can access We should note that if one wishes to consider issues of

only data items in the physical database at their own

transaction integrity, subjects are usually taken to be

security level. Notice that editing a database requires

sequences

both read and write accesses.

complex

of

these

operations.

definition

However

since

it

could is

be

more

This

used

slightly here

cumbersome

more

as

well.

and

adds

virtually nothing to the model for our purposes, we

4.

will use this simpler definition.

level

could

be

that

of

the

backend

security class could be could be that of the underlying

O = a finite set of objects

logical data item of which it is a replica. Fortunately, we need not choose. Both are used but for different

L = a finite lattice of security levels with

purposes. The physical security level of the data item

ordering

the confidentiality label for the data item. The

logical security level label provides information which is

necessary

for

correct

use

of

that

data,

i.e.,

of

a

data

item

always

dominates

its

C = an equivalence relation on O

logical

security level. The SINTRA system is assumed to

U = an equivalence relation on S

maintain the logical security level of a data items as data within the backend database which contains it.

Similar

considerations

hold

for

operations.

gp :S

the

user

who

submitted

it.

In

addition,

An

fp :O

write

levels.

Thus

operations

also

have

two

user,

and

a

physical

one

determined

by

L, a mapping of objects to (physical)

W = a predicate on S

associated security levels; a logical one determined by the

6

security levels

operations spawn other write operations at higher security

6 L, a mapping of subjects to (physical)

security levels

operation has a security level determined by the level of

$

A = {read, write}, a set of access modes

for

integrity purposes. Notice that the physical security level

Security

S = a finite set of subjects

database where it appears. Second, the data item

is

SINTRA

The model includes the following elementary items

There are two reasonable possibilities. First, the data security

the

Policy

What is the security level of a physical data item?

item

Formalizing

the

O represents the data items of the SINTRA system,

backend database in which the operation is actually

including all replicas, and xCy means that x and y are

executed.

replicas of the same logical data item. S represents the subjects and sUt means that s and t are the same

In the SINTRA architecture, the simple security and restricted

’-properties can be replaced (in the sense of

logical operation on copies, possibly different, of two copies of the same logical data item. W is used to

permitting user access to data) with the following

distinguish the write operations of S, and Ws means

functionally equivalent statements.

that s represents a write operation. We denote the

62

equivalence classes of x and s in C and U, respectively,

fl(x). The object x0 "represents" the logical data item

by C(x) and U(s).

associated

with

the

equivalence

class

of

x

in

C.

Virtually identical remarks hold for gl, gp, and U(s). These

elementary

items

satisfy

the

following

There are a number of other interesting properties

conditions

which

1)

œxœy: xCy v fp(x)=fp(y) .Y. x=y

2)

œxœaœb:

fp(x)=a

V

œsœaœb: Ws v gp(s)=a v (Wt v sUt v gp(t)=b)

SINTRA

f Ž(S×O×A),

where

Ž(X)

is the power set of X. A

V represents the change of state when request r is issued in state v. A system

3(V, T ,vinit)

over a set of

requests R is the finite state machine with states V, transition mapping T, and initial state vinit. A state v

Y. ›t

b>a .

is reachable in a system

3(V,

T ,vinit) if there is a

sequence for which v0 = vinit and for

#ic w a>c) w a=b

6)

to

v

œsœt: sUt v gp(s)=gp(t) .Y. s=t

5)

entities

subject s has access a to object o if and only (s,o,a)

œxœyœaœb: fp(x)=a v fp(y)=b v xCy .Y. ›c (b>c w a>c) w a=b

4)

these

Following [9], a system is a state machine with states

v b>a .Y. ›y (xCy v

fp(y)=b)

3)

relate

architecture which we leave to the reader.

0v Y fl(x) = gl(s) and

(s,x,write)

fp(x) = gp(s). A system

is secure if and only if all of its reachable states are both read secure and write secure. This corresponds to These conditions guarantee that the model accurately reflects

the

informal

model

discussed

the definition of system security given in [9,10].

earlier.

Conditions 1 and 4 insure that there is at most one

An alternative, but equivalent, way of approaching

replica

system

of

a

data

item

or

operation

at

any

given

security

for

those

types

of

systems

under

security level. Conditions 2 and 5 require that if a

consideration

data item or write operation exists at a security level

reorganizing

then

confidentiality secure if and only if for an operation op,

it

is

Conditions

replicated

at

all

higher

security

levels.

security

levels

to

arise

from

the

need

to

actually

replicate

read

obtained

conditions.

by

A

slightly

state

is

(replicated architecture-secure) if and only if all of its

operations.

reachable states are both confidentiality secure and

We define another mapping fl :O

6

integrity secure. L of objects to

(logical) security levels as follows

We assert that a system is secure if and only if it is

*

fl(x) = greatest lower bound {a xCy

Similarly, we define the mapping gl :S

RA-secure.

v fp(y)=a}

5.

*

0O

fl(x) for any x

0C(x)

follows

trivially

from

the

Security

and

The

SINTRA

Architecture

v gp(t)=a}

We consider the SINTRA architecture database from

and that xCy

the point of view of RA-security. The TFE is trusted to

implies that fl(x) = fl(y). Moreover, for each C(x) there is a unique minimal object x0

proof

6 L of subjects

gl(s) = greatest lower bound {a sUt

$

The

definitions.

to (logical) security levels as follows

Notice that fp(x)

these

be

where op is either a read or write operation, (s,x,op)

the

existance of lower security level replicas. Condition 7 eliminates

can

0v Y fp(x) = gp(s). A state is integrity secure if and only if (s,x,write)0v Y fl(x) = gl(s). A system is RA-secure

3 and 6 require replicas with possibly

noncomparable

here

connect the user to only the backend database with

for which fp(x) =

the

63

security which matches that of the user. Any

transactions,

and

therefore

any

read

or

write

its

own

security

policy

formal

model,

but

that

is

operations, submitted by a user and which have the

relatively easy. In addition, there are issues involving

security level of that user can act only on data items

the means by which the consistency of the replicas of

whose physical security level matches that of the user.

a logical data item will be maintained. These are

It is transparent, then, that the SINTRA system is

related to control of concurrent execution of user-

confidentiality secure. This means that that SINTRA

submitted

architecture prohibits low security level users from

There have been a number of concurrency control

gaining

algorithms

access

to

high

security

level

information.

transactions

developed

and

for

transaction

this

atomicity.

architecture

which

Hence, in the sense of confidentiality, the SINTRA

address

system has strong security properties. In fact, because

presented

of the physical separation of the backend databases,

integrating them into the model presented here is not

covert channels can arise only through faults in the

difficult,

TFE processes which, in addition to providing trusted

lengthy and dependent on the choice of particular

separation

algorithm.

of

database

access

management, Dealing

by

functions

users,

recovery,

with

covert

must

related garbage

channels

also

to

manage

in

issues[2,3,4,6,7,8].

a

sufficiently

though

the

All

formal

presentation

of

these

framework

would

be

are that

quite

transaction

collection,

in

these

these

etc.

Another plausible extension of the model presented

processes

here

is

to

non-database

applications.

Virtually

involves use of trusted mechanisms, minimization of

nothing

covert

databases. Any application for which the objects to

channel

bandwidths,

auditing,

etc.,

but

is

in

the

beyond the scope of this paper whose focus is on the

which

confidentiality obtained by physical separation.

replication,

access

access

is

e.g.,

analogously.

to

control

be

files,

model

is

specific

to

controlled

are

suitable

messages,

can

be

modeled

of

replica

Obviously,

the

issue

for

We also argue that the SINTRA architecture database

consistency integrity must be resolved adequately in

is reasonably integrity secure, though the argument

each case.

is less apparent. What we must argue is that write operations can be prevented from writing data items whose

logical

security

level

is

dominated

by

7. Conclusions

the

security level of the write operation. Most databases provide

mechanisms

operations

based

mechanisms

for

on

would

be

enforcing

values

of

utilized

constraints

the

to

data.

prevent

We have given an example of a trusted application

on

based on a replicated architecture and developed a

These

formal model of access control. We have demonstrated

actions

that

which would violate integrity security. If the logical security level labels, which are stored as data, are

the

then the non-label data would be equally corruptible, the

database

functionally

useless.

such

systems

confidentiality

integrity

is

that integrity security is as good as the integrity of

subject to corruption, e.g., by Trojan Horse attacks,

rendering

for

achieved solely as a function of the architecture, and

backend

systems'

data.

Based

on

this,

we

conclude that the replicated architecture approach is

The

a simple, straightforward, and promising approach to

integrity security of the system is enforced as strongly

the development of trusted applications.

as the integrity of the other data in the system. Thus providing integrity security properties for a SINTRA architecture providing

database

integrity

in

are any

equivalent database,

to

that

of

trusted

or

References

otherwise. 1.

D.E.

Bell

and

L.J.

LaPadula,

"Secure

Computer

Systems:Unified Exposition and Multics Interpretation,"

6. Extensions of the Model

MTR-2997, The Mitre Corp., March 1976.

There are other considerations in the security of the

2.

Oliver

Untrusted

SINTRA architecture database beyond those related

Costich,

"Transaction

Scheduler

in

a

Processing

Multilevel

Using

Database

an

with

Replicated Architecture", in Database Security V:Status and

to access control discussed above. The access control

Prospects, ed. Sushil Jajodia and Carl Landwehr, North-

model must be integrated with that for the trusted

Holland, 1992.

portion of the TFE, which we have assumed to have

64

3.

Oliver

Costich

Transaction

and

Problem

John for

McDermott,

Multilevel

"A

Multilevel

Secure

Database

Systems and its Solution for the Replicated Architecture", Proceedings

of

the

IEEE

Symposium

on

Security

and

Privacy, Oakland, CA May 1992.

4. Oliver Costich and Myong Kang, "Maintaining Multilevel Transaction

Atomicity

in

MLS

Database

Systems

with

Replicated Architecture", in Database Security VII:Status and

Prospects,

ed.

Thomas

Keefe

and

Carl

Landwehr,

North-Holland, 1994.

5. Judith N. Froscher and Catherine Meadows, "Achieving a

Trusted

Database

Management

System

using

Parallelism," in Database Security II:Status and Prospects, ed. Carl Landwehr, pp.151-160, North-Holland, 1989.

6. Sushil Jajodia and Boris Kogan, "Transaction Processing in

Multilevel-Secure

Databases

using

Replicated

Architecture" in Proceedings of the IEEE Symposium on Security and Privacy, pp. 360-368, Oakland, CA May 1990.

7. Myong Kang, Oliver Costich, and Judith Froscher, "A Practical Transaction Model and Untrusted Transaction Manager

for

Database

Security

a

Multilevel

Secure

VI:Status

and

Database

Prospects,

System",

eds.

Sushil

Jajodia and Carl Landwehr, North-Holland, 1993.

8. John McDermott, Sushil Jajodia, and Ravi Sandhu, "A Single Level Scheduler for the Replicated Architecture for Multilevel-Secure Databases" in Proceedings of the Seventh Annual Computer Security Applications Conference, San Antonio, Tx December 1991.

9.

John

McLean,

"Specifyng

and

Modeling

Computer

Security", IEEE Computer 23(1) pp. 9-16 (January 1990).

10. John McLean, "Security Models", in Encyclopedia of Software Engineering, John Wiley & Sons, Inc., New York, (forthcoming).

65