A Security Model for Object-Oriented Databases - Semantic Scholar

A SECURITY

Eduardo

MODEL

FOR OBJECT-ORIENTED

B. Fernandez,

Department

Ehud Gudes+,

2

Introduction

rules to database

* On leave from

Ben Gunon

that

rules

constraints are also required classes B3 and Al [DODC85 ] Another

as a guideline

for the

Israel

10$ Ol.00 @ 1989 IEEE

dlmenslon

by the

IS ownersfup

Orange

book

for

security

versus admlnfstratjon

In

Another relevant policy IS the choice between djscretlonary and mu/tJeve/ security The National Computer Security Center recommends the use of multilevel systems for general computational environments [DO DC85] For the environment considered here a d!screttonary policy seems adequate

I 10 CH2703-7/89/OOOO/Ol

IS needed

the first case users own and administer thetr data, In the second case the Information belongs to the enterprise, users are given access to It to perform their functfons and special users (admln!strators) control the structure and the use of the information Since a Data Base Management System IS used to support an enterprise, admlrmstratlon I> a more Ioglcal choice for this case Thfs view IS also supported by recentwork on enterprise pollc!es [Moff88] Additionally one may want to allow some (or all) user to define pr{vate databases

Include a collection of facts An object binds knowledge

University,

set of policles

rules

closed systems while flexlblllty indlcate$ open systems In general, when security is an important ob]ectlve, we should use a closed system. Another Issue IS the use of positive or negative authorization rules, For example, the system described In [Rab187] a subject may be uses positive and negative author lzatlons: demed access to an ob}ect either because It has no authorization for it or because It has a negative authorization on It The use of predicates for negative authorization present evaluation problems as well as possible contradictions In the security structure which may be hard to detect However, In a system with a rich data model negative author! zatlons may be needed to Negative authorization express subtle access constraints

develop here an authorization model for objectonented databases This model cons}sts of a set of pollcles, a structure for authorization rules, and an algorithm to evaluate access requests aga!nst the authorization rules For concreteness we use a specific database system, which is now under development at the University of Florida This system, ,ntended for CAD/CAM applications, Incorporates knowledge rules wrth a database of objects combined through an Object-Oriented Semantic Assoclatlon Model (OSAM*) ([ SUSY85], [SUSY88]) The of ob}ects

policles and authorization

A fundamental choice IS having an open or a c/osed system In an open system everything IS accessible unless forbtdden, while In a closed system we have the inverse situat!on Security requires

We

of relevant facts

Security

A coherent

Most of the current models for authorization in database systems were developed for relational databases [Fern81, Grlf76] Object-oriented databases have a much richer structure and those models are not adequate The addmon of semantic relationships makes the author! zatlon problem even more complex There IS a need for new models Until now very few authorization models for object-oriented databases have been proposed [Rabt87, Rab188] A related study [Tost88] considers a $malltalk system without a database system

is composed

to or to

design and use of a database system The cho{ce of policies for security IS Important because It can influence the flexlblllty, usablllty, and performance of the system [Fern81]

The Integration of oblect-oriented programming concepts with databases IS one of the most slgrmflcant advances In the evolution of database systems and several recent pro)ects are developing object-oriented databases Among the many Issues brought along by this combination, one that IS becoming important is the protection of Information

and a collection

Englneerlng

SectIon 2 considers security policies and the structure of the authorization rules for such a system, while Section 3 discusses access requests validation SectIon 4 develops an algorithm for access validation In the context of the OSAM* model, Section 5 shows some possible extensions, while the last section describes conclusions and directions for future work

We develop here an authorization model for objectorlented databases. This model consists of a set of pohcies, a structure for authorization rules, and an algorithm to evaluate access requests against the authorization rules For concreteness we use a speclflc database system to illustrate our model, but Its concepts are applicable to a range of ob)ect-ortented databases

database

Song

All the knowledge manipulation operations can be used express the rule$ Some of these rules could be Integrity secur!ty rules, i.e , they could be the basis for a mechanism enforce integrity or security

The Integration of object-oriented programming concepts with databases IS one of the most significant advances In the evolutlon of database systems and several recent pro}ects are developing object-oriented databases Among the many Issues brought along by this combination, one that IS becoming important IS the protection of information

1

and Haiyan

of Electrical and Computer Florida Atlantic University, Boca Raton, Florida 33431

Abstract

DATABASES

Multilevel

security

development Figure the OSAM*

for

object-oriented

databases

is under

1 illustrates model.

a port[on

of a university

(A few other

concepts

database

are introduced

using

A Student

in the

generalization indicated

by A, which

defines

propeflies

make

a set of attributes Figure

1 to define

(SA) could

have

for the

effective database of Figure 2, where It can be seen that all attributes of a class are Inherited by its subclasses (the dotted attributes are the inherited attributes). It IS clear now that access to some attr!bute of a class implies also access to the corresponding values In Its subclasses. Note that these values are a subset of those of the superclass, i.e., SSN as an attribute of Student represents only the SSNS of Students, while the values of SSN as an attribute of Person represent SSNS of Students as well

“’-

g Name

G /.,

/’ \\ \

(=J.A&, ,-, G

as of Teachers. These considerations

can be summarized

access to SSNS of all

We can also separate user rights defined by user authorlzatton rules as described above from admimstratlve rights, the ability to control the database access actions. Administrative rights are defined by admimstrative rules described by tuples (U, A, O, f). Examples of admlnistrat!ve access types are the rights to create and delete admimstratlve groupings of data, to define user This authorization rules, to revoke delegated rights, etc separation proved to be useful In a decentralized model [Wood79] and has been further elaborated in [Moff88]

association (G in Figure 1) Attribute “Year’’(year of graduation) is defined for Student and attribute “Course” for Teacher. Foreign Student (FS) is a subclass of Student. Attributes defined for subclasses reflect the fact that some features or properties only apply to specific subclasses, e.g., Visa is only meaningful for Foreign Students. Person, Student, Teacher, and Foreign Student are object classes (similar to Smalltalk classes). The!r attributes correspond to Smalltalk instance variables. In addition to the association, Figure 1 also shows an aggregation

some class Class Inheritance

Advisor

students (PI), but no access to their visas (P3), a Foreign Student Advisor (FSA) could have access to wsas but only to SSNS of Foreign Students (P2).

example of Section 3) Class Person (P) has attributes SSN (Social Security Number), Name (and maybe others). Classes Student (S) and Teacher (T) are subclasses of Person. The generic properties of Student and Teacher define Person through a generalization

association,

(FSA, R, (FS.SSN, FS.visa)) -- The Foreign Student Advisor can read SSN and wsa of foreign students

R2:

at SRI and Honeywell.

A

In the followlng

3olLcles. A

PI (Inheritance

pohcy)

-- a user that

o

has access to a class is

v!,.

allowed to have similar type of access in the corresponding subclasses to the attributes inherned from that class. P2 -- access to a complete class Implies access to the attributes defined in that class as well as to attributes inherited from a higher class (but only to the class-relevant values of these attributes) P3 -- an attribute

defined

for a subclass IS not accessible

Figure

1 A university

database

by

accessing any of its superclasses Additional

policies

are necessary to consider

predicates

and

multlple Inheritance. A discussion of possibilities for discretionary and mandatory systems is given in [SPO088] In general, an authorization rule is a tuple (U, A, O, p, f), which defines that subject or user U has authorization of type A

,\ ‘,,

(access type) to those occurrences of ob~ect class O for which predicate p is true (note that the word object here is not used in the sense of object-oriented databases but it represents any named entity) User U can grant the access right (O,A) if the copy f/ag f is true. This model has been used to describe most of the authorization systems for relational databases We use here a more specif!c version of these rules defined as below. An authorization

rule is a triple

(U, A,AO)

where

63

RI:

(SA, R, S.SSN) -- The Student of students.

2

Advisor

Assume

.-.’

E@ , ,,”” ,/..> ,. ----\, .-.

or user group, A IS an access type or set of access types, and AO is the set of attributes of the object to be accessed, I e ,A O = {Oi.al, A rule can either refer to AO as a whole or to its Oi.a~,...}. individual components. Attribute a, must be defined for object Oi, or inhented by It. For example, consider the graph of Figure following authorization rules are defined:

/.

..-.

U IS a user

( SW ‘--.

b

j ,;;-;:;;;.,

‘)(’ ’S.-

?M,ne I , Y... .“. _.’

,.”,5,

‘c) ‘1

v,,,

the

Figure2.

can read SSN

Ill

Effective

structure

of the database

of Figure

1

3

Validation

Access validation occurs by extracting a data This user query or from an executing program structure (U’, A’, O’), where U’ M the subject making the request, O’ is the requested object, requested access type This request is valldated authorization rules to dec!de totally or partially

Consider now rules RI and R2 of Section 2 According to Placement rule 1, RI must be placed at class Student SImllarly, R2 can only be placed at class Foreign Student

of access reauests

If the

request

request request

from a has a

A query-graph IS the subgraph of the security context defined by the nodes that the query Intends to access and their corresponding associations

(user, process) and A’ is the against the

should

be granted For the queries,

A security together

for

contexr

security

IS a set

purposes

of object A security

classes context

grouped may be

equivalent to a conventional view or other partitions of the database schema. A security context defines a partially ordered set of object classes (In terms of the assoclatlons) which dellmlts the access for user queries, t e , a data request M valldated using

Graph (defined rules are usually

later) for associated

above

we

define

the

following

two

IS Issued by SA and FSA

Q1:

read SSN for all students

Q2:

read SSN and wsa for all foreign

The corresponding

the rules in a speclflc context In Figure 3 we show a more global picture of the urmverslty database Security Context SC1 IS defined to Include Classes Person, Student, Teacher, and Foreign Student, as well as their corresponding associations. Valldatlon of a user’s request associated with this security context will only consider classes and associations wlthln SC1 (the portion In the dotted c[rcle) SC1 is used as a boundary when constructing the Query Security Authorization security contexl

example

each of which

query-graphs

are shown

students In Figure 4

m“-?!:’

the user’s query with a particular Query Graph for Q1

Foreign Student

‘\

d Visa

‘[’sSN

-.

)

\_/

Query Graph for Q, Figure 4

Query-graphs

for example

According to the pol!c!es of Section 2 we expect the followlng behavior as a result of the evaluation of the Indicated requests*: (SA,Q1) = (SA, Read, S SSN) -- all SSNS can be read (since we do not deal with exceptions or negative authonzatlons, we do not exclude, for example, foreign students or other subgroups that may not be accessible to a student adwsor ) (Policy PI)

\

I

\ \,

o

/“

Visa

\\

..

(SA,Q2)= (SA, Read, {FS Visa, FS SSN}) - -only SSNS of foreign students are to be read and not their wsas. (Policy PJ

/isc 1