Mo.co.za

A Taxonomy for Secure Object-Oriented Databases Martin S Olivier and Sebastiaan H von Solms (Published in ACM Transactions on Database Systems, 19, 1, 3–46, 1994)
Abstract
This paper proposes a taxonomy for secure object-oriented databases in order to clarify the issues in modelling and implementing such databases. It also indicatessome implications of the various choices one may make when designing such a data-base.
Most secure database models have been designed for relational databases. The object-oriented database model is more complex than the relational model and object-orientation is not based on a formal (mathematical) model like the relational model.
For these reasons, models for secure object-oriented databases are more complexthan their relational counterparts. Furthermore, since views of the object-orientedmodel differ, each security model has to make some assumptions about the object-oriented model used for its particular database.
A number of models for secure object-oriented databases has been proposed.
These models differ in many respects, because they focus on different aspects of thesecurity problem, or because they make different assumptions about what consti-tutes a secure database or because they make different assumptions about the object-oriented model.
The taxonomy proposed in this paper may be used to compare the various mod- els: Models that focus on specific issues may be positioned in the broader contextwith the aid of the taxonomy. The taxonomy also identifies the major aspects wheresecurity models may differ and indicates some alternatives available to the systemdesigner for each such design choice. Lastly, we show some implications of usingspecific alternatives.
Since differences between models for secure object-oriented databases are often subtle, a formal notation is necessary for a proper comparison. Such a formal no-tation also facilitates the formal derivation of restrictions that apply under specificconditions. The formal approach also gives a clear indication about the assumptions ∗Address of authors: Department of Computer Science, Rand Afrikaans University, PO Box 524, Auck- land Park, Johannesburg, 2006 South Africa; Email: molivier@rkw.rau.ac.za, basie@rkw.rau.ac.za made by us—given as axioms—and the consequences of those assumptions (and ofdesign choices made by the model designer)—given as theorems.
Keywords: Multilevel secure databases, Information Security, Formal Security Mod-
els, Object-orientation
Introduction
A number of models for multilevel secure object-oriented databases has been pro-posed. The variety exhibited by the proposed models is an indication of the greatnumber of possibilities that exist.
In this paper, rather than proposing another model, we approach the design of a secure object-oriented database by structuring the issues that should be consideredwhen such a database is designed. This makes it possible to compare the exist-ing models in a structured way to highlight the real differences. Specific choicesfor the discussed issues influence choices elsewhere in a given model: the struc-tured approach allows one to consider these effects systematically. A number ofthese effects are given and proven in this paper. The structured approach furtherallows researchers to focus on specific issues, rather than on a whole model at atime. Lastly, the described structure may be used to generate new models for secureobject-oriented databases; this has been done in [15] and [18].
Unfortunately, classifying such models is not an easy task. As Sandhu put it [20]: “The underlying assumptions adopted by each one and their motivating forcesare somewhat different. This makes a relative comparison difficult since different as-sumptions and motivations inevitably lead to different design trade-offs.” This doesmean that the taxonomy proposed by us may not be universally accepted. How-ever, if this paper prompts someone to design a model that does not fit the proposedtaxonomy, the taxonomy also serves a purpose.
The paper by Varadharajan and Black [25] follows a similar approach to this paper: they indicate some issues that are relevant when designing a secure databasemodel and also consider some of the alternatives that are available for each issue.
However, their approach is less formal and less general than ours.
The next section introduces existing work on security models for object-oriented databases, before the taxonomy is described in the following sections. Section 3describes the deductive approach we follow: definitions and axioms are given fromwhich theorems regarding secure database models will be proven. Section 4 con-tains a structured list of the parameters available to the designer of a secure databasemodel. Further, the axioms and definitions given earlier are used to derive the im-plications and limitations of choices available to the designer. Section 5 places themodeling stage (addressed by this paper) into context by looking at other stages in thedevelopment of a secure database. Section 6 discusses remaining (complex) issuesnot covered by the current paper, such as polyinstantiation and inference.
The primary original content of this paper is its structured approach to the design of secure object-oriented database models, simplifying the generation of new modelsand putting other research efforts into (a) context. In addition, the restrictions for classification of related entities (see parameter X2.3 later) are more comprehensivethan restrictions given by other authors. Further, the notation employed by us todescribe dynamic labeling (see parameter X3 later) has not been used for this purposebefore and some of the possibilities we give for this parameter are also original.
Security in object-oriented databases
The following security models serve as examples for our discussion. Here we onlymention the models; specific issues will be addressed when the design parametersare discussed.
• SODA [7, 8] is a model for a secure database based on a general object-oriented model. Objects or instance variables are assigned ranges of sensitivity levels.
Subjects are assigned clearance levels. Every message that travels through thesystem, carries with it a current sensitivity level and a clearance level. The cur-rent sensitivity level is adjusted whenever an object or variable with a highersensitivity is accessed. Rules, based on the current sensitivity level and theclearance level of a message and on an object’s or variable’s sensitivity level,determine whether the method should be permitted access to an object or vari-able.
• SORION [24] is based on the ORION object-oriented data model. Entities in the system (subjects, objects, variables, messages, etc) are assigned securitylevels. An extensive list of properties is given constraining assignment of levelsto entities. A given security policy constrains access to protected items basedon these security levels.
• Lunt has given some initial properties for a multilevel object-oriented database system [11]; here we will refer to these properties as the Lunt model. Theproperties specify minimum requirements for a secure database based on ageneral object-oriented data model.
• Views [6] allows an object to display different “views” of itself to other objects.
This is done by restricting from which other objects any given method may beinvoked. An alternative approach for defining views is given in [21]: multipleinterfaces may be defined for a single object. A ‘client’ object may then de-cide through which view it wants to access the object. The first approach ismore applicable for our purposes since it is precisely specified through whichinterface a given client object is permitted to access the protected object. Notethat the use of views in relational databases for security is well-known, see forinstance [12].
• The access control language of Mizuno and Oldehoeft [14] is based on ex- tended access control lists (ACLs): a four-tuple ACL entry specifies (1) whichuser may activate a method, (2) through which class the request may come,(3) through which specific object (class instance) the request may come and(4) lastly names the protected method.
• SECDB [17] is based on the Path Context Model (PCM) [2, 3, 4, 16]. A profile object is associated with every protected entity. A request collects baggage as it moves through the system. Before a request is allowed to access an entity,the baggage carried by the request is considered by the entity’s profile object;based on this baggage, the request is either allowed to proceed, or rejected.
When a protected entity is accessed, that entity’s profile is tagged to any mes-sages subsequently sent. Rules specify how the protection of other entitiesare influenced when they are accessed by a message that has such associatedprofiles.
• In the law-based approach as proposed by Minsky [13] a set of Prolog rules or laws may be specified to manage the exchange of messages in the system. Thisapproach is intended to describe general aspects of object-orientation such asinheritance; it can be used to describe security restrictions, but is too general tobe practical for this application. We include it nonetheless because the abilityto give constraints based on logic rules is useful, amongst other to control theassignment of sensitivity levels and to ensure integrity in general.
Approach
Our goals are twofold. Firstly we want to give a classification structure that will en-able one to compare different models for secure object-oriented databases. Secondly,we want to indicate some implications of the possible choices one can make.
To realise the first goal, we give a number of design parameters—issues one should consider when designing a model. We give eight such design parameters thatrepresent the major issues for consideration. These eight parameters are grouped intothree categories: X1 Labeling semantics: Underlying model and Protection interpretation;
X2 Structural labeling: Protectable entities, Label instantiation and Relationship
X3 Dynamic labeling: Authorisation flow, Sensitivity flow and Information flow re-
For most of these design parameters we list a number of alternatives that are avail-able. These parameters are described in detail in section 4.
Implications of choosing a specific alternative for a design parameter are given as theorems. Some proposed models already describe restrictions to their models[24, 11]; often it is not clear whether a model imposes such restrictions becausethey simplify the model in some way, or because they are necessary to ensure thatsecurity is not compromised. Further, it is not clear from those models how generallyapplicable such restrictions are, in other words do the restrictions still apply if someaspects of the model are modified? To address these problems, our assumptions aregiven as axioms; for theorems the circumstances under which they apply are given.
In order to classify and analyse models, the meaning of terms have to be clear; we describe the important terms as definitions. It is important to note that we donot claim that our definitions are the only proper definitions of the terms; nor do weclaim that our classification structure gives the final word on secure object-oriented database classification. We do claim that if our definitions fit a given model, thatmodel may be classified using the described classification structure and, also, thatthe given theorems are valid for such a model. We also hope that our definitions andclassification structure will prompt researchers to investigate models that do not fitthese definitions or the classification structure.
We now define a secure database for the purposes of this discussion.
Definition 1 (Secure database) An object-oriented database is secure if
1. No subject is able to obtain information without authorisation; 2. No subject is able to modify information without authorisation; 3. No mechanism exists whereby a subject authorised to obtain information can communicate that information to a subject not authorised to obtain it; and 4. No subject is able to activate a method without authorisation. This definition does not allow any covert channels—neither storage, nor timingchannels—which may mean that it is too strict for practical use. However, thesepoints cover the four primary issues addressed by models for a secure database. Is-sues (1) and (3) are normally addressed by models to enforce mandatory security,while issues (1), (2) and (4) are usually addressed by models to enforce discretionaryaccess control (see section 6.3).
In the remainder of this section we introduce notation and list the axioms that reflect the relevant assumptions we make about object-orientation. See [26] and [9]for an introduction to the object-oriented paradigm. Our view of this paradigm comesfrom the Smalltalk programming language [5].
An object o is a set of facets (methods, instance variables, etc)—ie if m is a method of o, we will denote it by m ∈ o; similarly, the fact that o has an instancevariable v, will be denoted by writing v ∈ o. The system consists of a set of objects.
We will refer to this set as U . (More precisely, v is the name of the correspondingvariable, m is the signature of the corresponding method and o additionally containsa unique identifier that distinguishes it from all other objects in the system U .) For the purposes of this paper a class is considered as a template for its instan- tiations; similarly the facets of a class are viewed as templates for the facets of theinstantiations of the class. Note that in many object-oriented systems (includingSmalltalk, our reference paradigm for this paper) classes are also objects (they areinstances of metaclasses) and are therefore also members of U . They also havefacets (class methods and class variables) that behave like their object counterparts.
If a class is indeed an object, any remarks made about objects also hold for classes.
However, as stated, the term class in this paper is used to refer to the ‘template func-tion’ of a class, to address specific issues concerning this aspect.
Let C be the set of all classes.
For any class c ∈ C, we will denote the set of superclasses of c by sup(c). In the case of single inheritance, sup(c) will consist of a single element. For any objecto ∈ U we will denote the class of o by class(o).
The assumptions we make about object-orientation are now stated as axioms.
Axiom 1 If an object o is in the system, then the class of o is also in the system;
formally
Axiom 2 Any facet x of an object o ∈ U is also a facet of the class of o; formally
Axiom 3 If a class c has a facet x, any instance o of c will also have the facet x;
formally
(x ∈ c) ∧ (∃o ∈ U )[c = class(o)] → x ∈ o Axiom 4 If a class c is in the system, then all the superclasses of c are also in the
system; formally
Axiom 5 For any class c ∈ C, if x is a facet of a superclass of c, then x is a facet of
c (it is either inherited or re-defined); formally
These axioms do not model polyinstantiation—we will return to polyinstantiation Design parameters
This section describes design parameters for a secure object-oriented database. Pa-rameters are grouped into the three categories To avoid confusion, we will use the term entity to refer to a passive item in a computing system—the term object is usually used in the literature for such a passiveitem; we will use the term object with the meaning usually associated in the object-oriented environment. The term subject is used to refer to an active item. Referringto the mathematical notation introduced earlier, an entity can be any object in U ; itcan be any class in C; it can also be any facet of such an object or class; formally theset of entities E is defined as follows E = U ∪ { x, o |x ∈ o ∧ o ∈ U } ∪ C ∪ { x, c |x ∈ c ∧ c ∈ C} Note that not all models allow all entities to be protected (see X2.1).
In a security model subjects normally send requests to entities. In the object- oriented environment an object is both the target for requests (ie it acts as an entityin the security sense) and an object is the issuer of requests to other objects (ie itacts as a subject). Consider any message. We will use the term subject to refer to the object that sent the message under consideration or, depending on the model, torefer to the sequence of objects that were involved in the sending of the sequence ofmessages prior to the message under consideration; the first item in such a sequenceis usually the human ‘object’ that initiated the chain of messages; the other itemsare normal objects that received a message and then sent messages to other objects.
We expand on this description when we discuss the underlying model (X1.1) and theflow of authorisation (X3.1). Although the precise definition of subject depends onthe specific security model, we will assume that it is defined and that a set S of allsuch subjects exists; the exact composition of S will be discussed later. The termentity refers to an object, method or variable (or other facet) in the role of receivingthe message under consideration.
Labeling semantics
We use the term labeling to refer to the assignment of a security category to an item.
In the case of a subject a clearance is usually assigned. In the case of an entity asensitivity or classification is usually assigned.
Two aspects deserve consideration under the heading labeling sematics: (X1.1) The model on which labeling is based; and
(X1.2) Exactly what is protected if an item is labeled.
X1.1 Underlying model
The model on which labeling is based falls in one of three broad categories, or acombination of some of these categories: • Explicit levels: sensitivity levels are assigned to entities and clearance levels to subjects. These levels are normally integers. Rules determine when a subjectmay access an entity; often a subject may read an entity if the subject’s clear-ance level dominates the entity’s sensitivity level. In general, the level labelsneed not be integers—as long as the ≥ relation is defined for (some of) thelabels associated with the subjects and the entities. In many models the samelabel act as an indication of an item’s clearance when viewed as a subject andits sensitivity when viewed as an entity.
• Access control lists (ACLs) are lists associated with entities, containing the identities of subjects that are authorised to access the entity. Extensions ofACLs have been proposed that do not only contain the identity of authorisedaccessors, but also the path such a request has to follow; see for example [2,14].
• Capabilities are non-forgeable identifiers possessed by subjects. Such a capa- bility is similar to a key for a padlock: a subject will be allowed to access aprotected entity only if it presents an acceptable capability.
A combination of the first two approaches is popular: Entities are classified using a sensitivity level and a category. Only subjects with a proper clearance level and be-longing to the specified category are allowed to access the entity. Classifications thus form a (partially ordered) lattice. However, most models based on this combinationignore the category aspect of the classification, and only address the (fully ordered)classification levels when developing the model.
With the underlying models in mind, we can consider the set of subjects S again.
A subject may be an object (including human ‘objects’ using the database), a combi-nation of objects, etc. The following are examples of subjects (ie elements of S) thatmay be authorised to access an entity e: • An object with a clearance level that dominates the sensitivity level of e; • An object in possession of a capability to access e; • An object listed in the access control list of e; or • An acceptable access path (as defined in PCM [3] or Mizuno and Oldehoeft’s extended access control lists [14]) via which a request may reach e.
Whichever underlying model is used, it is often necessary to ensure that one entity is ‘more protected’ than a second entity, implying that only a subset of theauthorised users of the less protected entity is allowed to access the more protectedentity. In such a case we will say that the ‘more protected’ entity has a higher clas-sification, even if we are not using explicit levels as the underlying model. We willalso say that the classification or clearance of an item dominates that of another item,meaning that the first has a higher (or equal) classification or clearance than the sec-ond item. To formalise this, let subj (e) be the set of all subjects authorised to accesse, with subj a function Note that the definition of subj represents a generalisation of the simple security property of the Bell-LaPadula model [1].
Without defining the sensitivity of an entity formally, we will denote the sensi- Suppose that all the subjects authorised to access an entity e1 are also authorised to access an entity e2, in other words that subj (e1) ⊆ subj (e2). This means thateither e1 and e2 are equally sensitive, or an s ∈ S exists that may use e2 but note1, in which case e1 is ‘more sensitive’ than e2. We will indicate this by writingL(e1) ≥ L(e2). Formally L(e1) ≥ L(e2) ⇔ subj (e1) ⊆ subj (e2) Let Llow indicate the sensitivity of an entity that may be accessed by all subjects in the system and Lhigh indicate the sensitivity of an entity that may be accessed byno subject in the system. Then, for any entity e ∈ E, Because this inequality holds for any entity, the least upper bound and the great-est lower bound of any set of sensitivities are defined. (In mathematical termi-nology, L(E) is a lattice.) We will denote the least upper bound of a sequence of entities e1, e2, e3, ., en by e1, e2, e3, ., en , and the greatest lower bound by The function subj returns the subjects that may access a given entity. It is also useful to define an ‘inverse’ function, indicating which entities may be accessed bya given subject. For any subject s ∈ S let ent(s) be the set of all entities that may beaccessed by s. Formally, ent is a function where PE denotes the powerset of E and, for all s ∈ S X1.2 Protection interpretation
The second aspect regarding labeling semantics is the question exactly what is pro-tected if an item is labeled. Some models attempt to protect the fact that an itemexists, while others protect the contents of an item; Smith [22] identified three “di-mensions of protection”, where 2. The fact that the data exists is classified; 3. The rule for classifying is itself classified.
We will refer to the models that hide the existence of data as existence protection andto models that only protect the contents against illegal access as access protection.
Note that, in the case of access protection, users may know that a variable or methodexists, but will get ‘access denied’ error messages when they try to activate a methodor read or modify an instance variable without authorisation. Further note that theuse of access protection presents a possible covert channel—a highly cleared subjectmay create an object under certain circumstances, and an uncleared subject mayobserve the fact that this object has been created (even though not able to access it)[10].
Definition 2 In an existence protected model the fact that a labeled entity exists is
hidden from unauthorised subjects.
In an existence protected model, if the existence of one entity implies the exis- tence of a second entity, then the sensitivity of the first entity must be at least as highas that of the second—ie Lemma 1 In an existence protected model, if
(e1 ∈ E) ∧ (e2 ∈ E) ∧ (e3 ∈ E) ∧ . ∧ (en ∈ E) → f ∈ E and s ∈ subj (ei) for every i then s ∈ subj (f ). If this were not the case then a subject cleared to access every ei, but not f , will be able to infer that f exists, contrary to the definition of existence protection.
This fact, together with the axioms given earlier, leads to a number of interestingtheorems—see later.
To illustrate existence protection, suppose that a class EMPLOYEECLASS has a protected method INCREASESALARY; unauthorised subjects will simply not ‘see’this method in the class. Since an unauthorised subject cannot determine that thismethod exists, it cannot possibly access it. Similarly, this class may have instances‘John’ and ‘James’. A subject cleared to access John’s information, but not James’s,will simply not know that James exists.
One advantage of existence protection is illustrated by the following example: If a subject can see that EMPLOYEECLASS has a GETUNDERCOVERASSIGNMENTmethod, the user will be able to infer that some employees have undercover assign-ments even if the user is not able to activate that method.
A disadvantage of existence protection is that a subject that does not know that an object already exists, may create it; in the example above, a subject that does notknow about John’s existence may insert a John object into the database—if the createrequest is rejected, the user will infer that the object existed, contrary to the labelinginterpretation. This interpretation therefore necessitates polyinstatiation with its as-sociated problems (see section 6.1). A similar problem occurs when a subject definesa class that already exists without the subject knowing.
Conjecture 1 An existence protected model must support polyinstantiation.
Lunt (amongst others) uses existence protection. Property P3 of SORION also In some cases existence protection is not practical. One example is when sensi- tivity cannot be pre-determined; for example when it depends on In the case of content-dependent sensitivity the sensitivity varies according to thecontent of the item: a salary may be classified secret if it is below $100 000, but topsecret if it is above that amount. Context-dependent security addresses the aggrega-tion problem: the sensitivity of a combination of entities are often higher than thatof the individual entities. As an example, the list of employees in a firm may be un-classified, the list of salaries earned may be secret, but the list of employees with thesalary each earns may be top secret. An example of time-dependent sensitivity is amilitary database entry containing the date on which the enemy will be attacked—itwill be top secret up to that date but unclassified after that. In these cases existenceprotection may be meaningless: if a subject is allowed to access a SALARY variablein one object and the SALARY field does not exist in another similar object, it is easyto infer that the particular variable does in fact exist, but is classified. Thuraisingham[24] gives some solutions to this problem, but it still does not solve the problem thatthe existence of hidden items may be inferred.
Definition 3 In an access protected model, an unauthorised subject is not allowed
to access a protected entity; ‘not allowed to access’ means that
• Any unauthorised message sent to a protected object will fail; • Any unauthorised message sent to a protected method will fail; and • Any method attempting to access (read or write) an instance variable illegally Note that ‘accessing an object’ does not include passing that object as a parameter;a message that is not authorised to acces an object may pass it as a parameter whenit sends a message to another object.
Some underlying models are only aimed at preventing an unauthorised subject from obtaining information from a protected entity (compare the simple securityproperty of Bell-LaPadula [1]). Information flow restrictions (X3.3) then restrictthe locations where information may be sent or written (compare the *-property ofBell-LaPadula). To accommodate these models, we allow a weak form of accessprotection where access means obtaining information with the aid of a method orreading a variable.
Some remarks on message failing. Note that failing does not only occur in access protection: In an existence protected model, an object may receive a message froman authorised subject and activate the corresponding method. If this method now • Sends a message to an object that does not exist as far as the original subject is • Sends a message to another method that does not exist as far as the original • Accesses a variable that does not exist as far as the original subject is concerned then, in any of these cases, can the message sent by this subject not complete.
For consistency, if a message fails for security reasons, we will assume that it behaves exactly as if it fails in the case where the object, message or variable reallydoes not exist. One possibility is to return a special value nil whenever a variableis read that does not exist (or is hidden) and to ignore any attempt to write a valueto a non-existent (or hidden) variable. Similarly, messages to such non-existent (orhidden) methods may just be ignored, and the value nil may be returned by any suchmessage from which a return value is expected. This solution could be dangerous be-cause errors in the database software could be overlooked; other solutions should beinvestigated. Further, if a variable contains a value for some subjects and nil for oth-ers, the model employs a form of polyinstantiation (see section 6.1)—we thereforedo not devote further attention to this possibility in this paper.
Note that neither existence protection, nor access protection implies that the con- tents of an object can never be accessed by a subject that is not authorised to accessthe object: in the case of a composite object a constituent part may be independentlyaccessable and have a different (lower) classification; it is then possible that the partmay be accessed by subjects not authorised to access the composite object. This may,for example, occur where the relationship between two entities is more sensitive than the contents of the entities themselves. This aspect will be mentioned again in thenext section and discussed in the section on aggregation.
Further note that existence and access protection are not the only protection mod- els. Other protection models worth consideration include the following: • Use existence protection for objects, but hide classes totally from all subjects (except the database system itself which needs to access it to create instancesof the class). Thus no subject can directly gain information from the class and,from there, infer information about the instances of the class. In this case themodel will not attempt to limit conclusions about the class, but will attempt tolimit the inferences one can make about one instance of a class by accessinganother instance.
• Use access protection for classes (and therefore do not attempt to hide the structure of objects), but do hide the fact that an instance exists from a subjectnot authorised to access the instance.
We do not consider these possibilities further in this paper.
Structural labeling
Here we consider the influence of the structure of the data on the labeling of entities.
The object-oriented model has a rich variety of entities with relationships be- tween such entities. For example, an object is an instantiation of a class; an objectmay be an aggregation or composition of other objects; objects contain variables andmethods; etc. These entities and relationships describe the structure of an object-oriented data model.
(X2.1) Which entities may be labeled? Possibilities include objects, classes, meth-
(X2.2) How and when are entities labeled?
(X2.3) Does the model place restrictions on the labeling of related entities? For
example, is a subclass necessarily more sensitive than its superclass? X2.1 Protectable entities
A model for a secure object-oriented database must specify which entities may beprotected. In this section we consider some possibilities and indicate implications ofallowing certain entities to be protected. Examples of protectable entities are objects,methods, instance variables, classes, class methods, class variables, etc.
If only objects are allowed to be labeled, the whole object has the same sensitiv- ity; we will refer to such an object as a single level object. If portions of an object (iemethods and instance variables) may be labeled individually, it provides finer granu-larity from a security viewpoint. Because the sensitivity of portions of such an objectmay be different, we will refer to such an object as a multilevel object.
Models that only support single level objects and models that support multilevel objects have been proposed and both types seem practical [11]. Models supporting only single level objects have the benefit of being simple; also many of the relation-ship restrictions given later (X2.3) are trivial in such a case. On the other hand, itseems quite natural to label the query and update methods of the same object differ-ently, because there is an inherent difference between the sensitivities of these twomethods. Similarly, it seems natural to label the SURNAME and SALARY instancevariables of an EMPLOYEE object differently, also supporting the case for multilevelobjects.
Multilevel objects present the multilevel update problem [24]: suppose that some variables are classified higher (or merely different) than other variables of the sameobject. The problem to be answered is at what clearance level must a subject be toupdate the object. If the subject is at the high level, and writes variables with a lowersensitivity, then the subject has ‘written down’ possibly compromising security. Ifthe subject is at a lower level, it is not authorised to access the more sensitive vari-ables anymore. The only solutions are to either log out and log in for every concernedsensitivity or to polyinstantiate some variables (or the whole object). As Thuraising-ham points out, neither of these solutions is desirable. Note that this problem onlyoccurs when instance variables are allowed to have a different sensitivity than thecontaining object; methods may differ without any adverse effects. Further, see [10]for a discussion of a number of problems associated with multilevel objects.
Classes also have entities that may be protected. Remember that classes are ob- jects themselves; they have methods (known as class methods, such as CREATE),they have variables (known as class variables) and they are instantiations of meta-classes. Therefore any remarks about labeling of objects or their facets also hold forthe ‘object aspects’ of a class. Note that a class variable must be labeled in the classbecause it is available to all instances of the class (although the sensitivity in a par-ticular instance may be higher than the sensitivity specified in the class—see X2.3).
It is also possible to label the ‘template aspects’ of classes (including methods andvariables defined there) with the intention that the given sensitivity label should ap-ply to all instances of the class, rather than to protect the class itself—we address thisbelow (X2.2).
The protectable entities of SODA are instance variables and objects; however SODA allows either the entire object to be labeled, or the individual instance vari-ables, but not both.
In addition to the usual protectable entities SECDB also allows ‘layers’ of objects to be labeled: The class of an object may have many superclasses. Portions of anobject are therefore defined in a number of (super-) classes. These portions formlayers—the innermost layer defined in the ‘highest’ superclass, while the outermostlayer is defined in the (immediate) class of the object. Protecting the outermost layercorresponds to protecting the entire object in other models; labeling any other layerprotects those portions of the object that were defined in the corresponding superclassand any of its superclasses.
X2.2 Label instantiation
An object-oriented system is a dynamic system: objects are instantiated and de-stroyed continually. In order not to compromise security, newly created (instantiated) objects must be protected immediately. The initial sensitivity of an entity reflects theinherent sensitivity of the entity. For example, it can be pre-determined which sub-jects will be allowed to invoke the INCREASESALARY method of an EMPLOYEEobject. Normal database activities will have no influence on the sensitivity of thismethod. Similarly, the inherent sensitivities of the instance variables of such an ob-ject may be pre-determined reflecting the sensitivity of the value of such a variableor the sensitivity of the relationship between the object and the contents of that vari-able. However, some models allow the sensitivity of such a variable to be increaseddynamically if a particularly sensitive value is stored in that variable. Stated differ-ently, the initial sensitivity of a variable reflects the sensitivity of the ‘container’; insome cases the ‘contents’ of the variable will be more sensitive than the ‘container’itself, and at that point the sensitivity of the variable may be higher than its initialsensitivity. Here we are only interested in the initial sensitivity; see dynamic labelinglater for details about re-labeling of entities.
Three primary possibilities exist for determining the initial sensitivity of an ob- 1. The class must be labeled and the label(s) specified for the class must apply for 2. Every object (and possibly its variables and methods) must be explicitly la- beled when or after the object is instantiated; [25] proposes that the methodthat instantiates a new object may specify the sensitivities of the interface vari-ables (parameters) from which the class of the new object may then derive thesensitivities of all instance variables; or 3. Constraints may be specified—ie separate (logic) rules that determine the sen- sitivity of a newly instantiated object and then ensures that the entity is sensi-tivity labeled immediately.
Of course, a combination is also possible with default labels derived from the classand individual labels given after instantiation where the default labels do not suffice.
Since it is unreasonable to trust normal methods to sensitivity label a newly in- stantiated object, and since constraints fall outside the scope of this work, the mech-anism that will be used in this paper for labeling of newly instantiated objects isinheritance: mechanism (1) above. SODA and SECDB use this mechanism.
X2.3 Relationship restrictions
The third question—on the labeling restrictions of related entities—leads to someinteresting results. The relationships to consider are: • Aggregation: The relationships that exist between an object and its facets • Instantiation: The relationships that exist between a class and its instances; • Inheritance: The relationships that exist between a class and its subclasses; • Composition: The relationships between objects that are combined into a larger • Association: The relationships for objects that exist in order to associate two • Data structure membership: The relationships between a data structure (such as a list) and a member of the data structure; also the relationships amongstmembers themselves.
This paper focusses on the first four types of relationships; to address data struc- tures additional axioms will have to be included for any specific data structure.
Relationship restrictions may be divided into compulsory and additional restric- tions. Compulsory relationship restrictions are those restrictions that a model mustenforce as a result of design choices made elsewhere or as a result of the inherentobject-oriented structure. Additional relationship restrictions are other restrictions amodel may prescribe because they simplify the model or have some other benefit.
We discuss compulsory relationship restrictions first.
The first relationship restrictions we consider, are imposed by the aggregation of an object. An object encapsulates everything inside it. This implies that a facetthus encapsulated cannot be accessed by a subject that is not allowed to access theencapsulating object in the first place. This holds whether the model uses existenceprotection or access protection.
Lemma 2 (Encapsulation corollary) The sensitivity of a facet of an object domi-
nates the sensitivity of the object itself, ie L( x, o ) ≥ L(o) for every facet x of any
object o. Similarly, the sensitivity of a facet of a class dominates the sensitivity of the
class itself, ie L( x, c ) ≥ L(c) for every facet x of any class c.
Proof: This lemma follows from the fact that, if a subject is not authorised to access
o, that subject is also not authorised to access any facet x of o, that is s ∈ subj (o) →
s ∈ subj ( x, o ). Therefore, by contrapositive, s ∈ subj ( x, o ) → s ∈ subj (o).
Hence, subj ( x, o ) ⊆ subj (o). From the definition of L follows that L( x, o ) ≥
L(o).
The proof for the second part of the lemma is similar.
This lemma is similar to the facet property (property 3) of Lunt.
Our second group of relationship restrictions are imposed by instantiation: the relationships that exist between a class and its instances.
If the model uses existence protection, both inheritance and instantiation restrict labeling: If (part of) a class is existence protected, that (part of the) class does not ex-ist as far as an unauthorised subject is concerned. However, if such an unauthorisedsubject is authorised to access a subclass or an instance of the protected class, thisprotected information becomes visible to the subject (even if not accessible by thesubject): from the subclass the subject can ‘see’ the names of methods, instance vari-ables and even the composition of the superclass; similar information can be gatheredfrom an instance about the concerned class. This motivates the next theorems.
Lemma 3 In an existence protected model, the sensitivity of an instance must dom-
inate the sensitivity of its class, ie
Also, the sensitivity of a facet in an instance must dominate the sensitivity of the facetin the class and also dominate the sensitivity of the instance itself, ie (∀o ∈ U )(∀x ∈ o)[L( x, o ) ≥ L( x, class(o) ), L(o) ] Proof: From axiom 1 we know that o ∈ U → class(o) ∈ C. Since U ⊆ E and
C ⊆ E, it follows that, for every o ∈ U ,
Applying lemma 1 proves that L(o) ≥ L(class(o)).
From axiom 2 x; o ∈ E → x, class(o) ∈ E. Applying lemma 1 to this proves L( x, o ) ≥ L( x, class(o) ). From lemma 2 follows that L( x, o ) ≥ L(o)and therefore (∀o ∈ U )(∀x ∈ o)[L( x, o ) ≥ L( x, class(o) ), L(o) ] From the discussion on label instantiation above (X2.2) we may assume that similar restrictions exist for the access protected model. We state this as an axiom.
Axiom 6 In an access protected model, if a class (including variables and methods
defined in that class) is sensitivity labeled, the intention is that such labels should
apply for all instantiations of the class; in other words, the sensitivity of an instance
must dominate the sensitivity of its class; and the sensitivity of any facet of an in-
stance should dominate the sensitivity of that facet as defined in the class.
Theorem 4 (Instantiation restriction) The sensitivity of an instance must dominate
the sensitivity of its class, ie
Property 2 of Lunt (when interpreted for classes and instances) and property P7 of SORION are the same as our instantiation restriction (theorem 4).
Theorem 4 constrained the sensitivity of an instance of a class. The following theorems constrain the sensitivity of a facet of such an instance.
Theorem 5 In an existence protected model, the sensitivity of a facet x of an object
o is given by
Proof: Let c = class(o). From lemma 3, L( x, o ) ≥
subj ( x, o ) ⊆ subj ( x, c ) ∩ subj (o). Let s ∈ subj ( x, c ) ∩ subj (o). Thens ∈ subj ( x, c ) and s ∈ subj (o). From axiom 3, since o ∈ U and c = class(o) and x ∈ c, the fact that x ∈ o is implied. According to lemma 1, s ∈ subj ( x, o ). There-fore subj (o) ∩ subj ( x, o ) ⊆ subj ( x, c ). As indicated earlier, subj ( x, o ) ⊆subj ( x, c ) ∩ subj (o). Therefore subj ( x, o ) = subj ( x, c ) ∩ subj (o), and thus The practical implication of this theorem is given in the following corollary.
Corollary 6 In an existence protected model, the only way to adjust the sensitivity
of a facet x of an object o from its inherited sensitivity—L( x, class(o) )—is by
increasing the sensitivity of the entire object o.
Theorem 7 In an access protected model, the sensitivity of a facet x of an object o
dominates both the sensitivity of the facet in its class and the sensitivity of the object
itself, ie
Proof: From lemma 2, we know that L( x, o ) ≥ L(o). From axiom 6 follows that
L( x, o ) ≥ L( x, class(o) ).
Our third group of relationship restrictions are imposed by inheritance: the rela- tionships that exist between superclasses and their subclasses.
Lemma 8 In an existence protected model, the sensitivity of a subclass must domi-
nate the sensitivity of its superclass(es), ie for any class c ∈ C
Proof: This proof is similar to the proof of the first part of lemma 3.
Axiom 7 In an access protected model, if a class (including variables and methods
defined in that class) is sensitivity labeled, the intention is that such labels should be
inherited by all its subclasses (unless the variable or method is re-defined, in which
case it may be re-labeled); in other words, the sensitivity of a subclass must dominate
the sensitivity of its superclass(es); and the sensitivity of any facet inherited from a
superclass should dominate the sensitivity of that facet in the superclass.
Note that this axiom does not apply to SECDB: if a class is labeled in SECDB,the intention is that that label should be applied to the corresponding layer of anyinstance of that class or of any instance of some (eventual) subclass of the labeledclass. Results based on this axiom will thus not hold for SECDB.
Theorem 9 (Inheritance restriction) The sensitivity of a subclass must dominate
the sensitivity of its superclass(es), ie for every class c ∈ U
Property 2 of Lunt (when interpreted for superclasses and subclasses) and prop- erty P9 of SORION are the same as our inheritance restriction (theorem 9).
Lemma 10 In an existence protected model, if any class c ∈ U inherits a facet x
from a superclass d ∈ sup(c) or re-defines a facet x that occurs in a superclass d,
then
Proof: This proof is similar to the proof of the second part of the lemma 3.
Property 4 of Lunt (when interpreted for superclasses and subclasses) is the same Theorem 11 In an access protected model, if any class c ∈ U inherits a facet x from
a superclass d ∈ sup(c), then
Proof: This proof is similar to the proof of the second part of the lemma 4.
Multiple inheritance is supported if the data model allows a class to, simultane- ously, be a subclass of more than one superclass. In general, if multiple inheritanceis supported it is necessary to specify which facet (variable or method) will be inher-ited if it is defined in more than one superclass. In the case of existence protectionproblems may occur: Assume that a subject is cleared to access facet F in class C1.
Assume further that class C3 is a subclass of both classes C1 and C2. If the subjectdoes not see the facet F in C3 it implies that facet F is inherited from C2. The sub-ject can therefore infer that facet F exists in both C2 and C3, although the subject isnot cleared to know about the facet’s existence. This is addressed by the followingtheorem.
Theorem 12 (Facet inheritance restriction) If, in an existence protected model, x
is a facet of a class c and x also appears in (at least) one superclass of c, then the
sensitivity of x, c is bounded as follows, for every superclass d ∈ sup(c) that has
a facet x
Further, if x is inherited from a specific superclass d ∈ sup(c), then, for everysuperclass d ∈ sup(c) that has a facet x L( x, d ), L(c) ≤ L( x, c ) ≤ L( x, d ), L(c) Proof: The fact that L(c) ≤ L( x, c ) was stated in lemma 2. The fact that, if x
is inherited from a specific superclass d , then L( x, d ), L(c) ≤ L( x, c ) was
stated in lemma 10.
To prove the rest of the inequality, ie to prove select any d ∈ sup(c) such that x ∈ d. According to axiom 5 this implies thatx ∈ c. According to lemma 1 for any s ∈ S for which both s ∈ subj ( x, d ) ands ∈ subj (c) it must also hold that s ∈ subj ( x, c ). Thus s ∈ subj ( x, d ) ∧ s ∈subj (c) → s ∈ subj ( x, c ) and therefore subj ( x, d ) ∩ subj (c) ⊆ subj ( x, c ) Now assume, contrary to what is being proven, that L( x, c ) > L( x, d ), L(c) .
Then L( x, c ) > L( x, d ) and L( x, c ) > L(c). From the definition of L it fol-lows that subj ( x, c ) ⊂ subj ( x, d ) and subj ( x, c ) ⊂ subj (c). Thus we have subj ( x, c ) ⊂ subj ( x, d ) ∩ subj (c) which contradicts equation 1 and proves the theorem.
This theorem makes a number of statements about inherited (and re-defined) facets in an existence protected model. Some of these statements are given in thenext corollary.
Corollary 13 In an existence protected model
1. If a class c inherits a facet x, c , the sensitivity of x, c may only be different from its sensitivity in the superclass when L( x, c ) = L(c); in other words, theonly way to increase the sensitivity of an inherited facet x, c , is by increasingthe sensitivity of the entire class c. (Corollary 6 made a similar remark aboutinstances.) 2. The sensitivity of a re-defined facet x, c must be dominated by that of every like-named facet in any superclass of c, whenever the sensitivity of the like-named facet dominates the sensitivity of c. 3. If a facet is defined in only one superclass of a given class c (or the class c has only one superclass, or the object-oriented model only allows singleinheritance), that facet may be inherited without any problems; the sensitivityof the inherited facet will be the least upper bound of its sensitivity in thesuperclass and the sensitivity of the class c. 4. The sensitivity of an inherited facet x, c must be dominated by the sensitivity of all like-named facets in superclasses of c, whenever the sensitivity of thelike-named facet dominates the sensitivity of c. The last point of the corollary above indicates two strategies an existence pro- tected model may follow to prevent the problems presented by multiple inheritance: 1. Ensure that the like-named facet with the lowest sensitivity is always inherited; 2. Ensure that the sensitivity of a subclass is an upper bound for the sensitivities of all concerned facets in superclasses.
Strategy 1 is only feasable if a facet with a lowest sensitivity does indeed exist; if thesensitivities are partially ordered the existence of such a facet is not guaranteed. Ofcourse, a model may also solve these problems by disallowing multiple inheritance.
Property 5 of Lunt requires that the facet with the lowest sensitivity must be inherited—ie strategy 1 above. Properties P15 and P16 of SORION require that thefacet with the highest sensitivity must be inherited—contradictory with this theorem.
Next, we consider the implications of two objects that are related because one is part of the other object, or because the two objects are associated in some other way.
To simplify matters, we will assume that one object contains (in one of its instancevariables) the object identifier of the other object; the object identifier is a uniquevalue associated with every object. All the properties previously derived for facetsof an object also hold for the object identifier.
Note that the sensitivity of an object is not important if that entire object is re- trieved from a variable, passed as a parameter to another object, etc. Since the objectis an encapsulated unit it still has its original protection wherever it is moved, copiedor stored; access to the contents of the object (such as its variables and methods)is what is protected: a retrieved object cannot even be compared to another objectwithout using one of the methods of the concerned object(s). This holds for bothexistence and access protection. In the case of existence protection the ability of asubject to retrieve an object without permission to access the object will not compro-mise security: without accessing the object the subject will not be able to determinewhether the retrieved object is the nil object (indicating that no actual value was con-tained in the variable) or some actual object. The subject is therefore not able to usethis ability to make any inferences about the existence of objects.
However, suppose that a subject can retrieve an object identifier (and not the ob- ject as a whole). Further suppose that the subject can ‘inspect’ the identifier beforeattempting to access the corresponding object. Then the subject may infer that anobject exists (a problem in the case of existence protection). Further, by comparingthis identifier with other identifiers obtained from other variables it becomes possi-ble to make complex inferences (see section 6.2). An access protected model thatallows subjects access to object identifiers can simply inform the user that access isnot permitted if the subject is not properly authorised to access the identifier (but,possibly, the variable itself). In the case of existence protection most subjects willhave access to the nil object—therefore if access to an object identifier is denied thesubject will be able to infer that the accessed object is not nil and make the inferencethat some other object exists—contrary to the definition of existence protection. Thisis covered by the next axiom.
Axiom 8 In an existence protected model that allows direct manipulation of object
identifiers, any subject authorised to access a variable, must also be able to access
the object identifier of the object contained in the variable. The sensivity of any such
variable is the least upper bound of that of the variable itself and the sensitivity of
the contained object identifier.
However, since the sensivity of a variable in an existence protected model is uniquely determined by theorem 5, this means that the sensitivity of the contained object cannot exceed that of the containing variable: Theorem 14 In an existence protected model that allows direct manipulation of ob-
ject identifiers, the sensitivity of a variable dominates the sensitivity of the object it
contains, ie if variable v of object ov contains object oi then
Proof: If i is the object identifier of object oi then it follows from lemma 2 that
From axiom 8 we know that the sensitivity of variable v, ov , while it contains object oi, is the least upper bound of the sensitivity of variable v, ov itself and thesensitivity of the contained object identifier. However, according to theorem 5 thesensitvity of variable v, ov (irrespective of its value) is precisely determined by thesensitivity of that variable in the class (L( v, class(ov) )) and the sensitivity of thevariable’s object (L(ov)). Therefore the the sensitivity of a variable cannot be morethan its labeled sensitivity, which means we must have Note that this theorem deals with a static situation: viewed at any specific instant the contents of a variable cannot be more sensitive than the variable; however, it maybe possible to increase the sensitivity of a variable when more sensitivity is required(if the circumstances of theorem 5 apply, the sensitivity of the variable is increased byincreasing the sensitivity of the entire object). This is addressed later when dynamiclabeling (X3) is discussed.
Properties P18 and P19 of SORION state that the sensitivity of an aggregate object dominates the least upper bound of all its components. Since SORION usessingle level objects, this property corresponds to our theorem 14. One may concludefrom property P3 of SORION that SORION does use existence protection and thatit allows direct access to the object identifier (or “object name” as referred to inproperty P3). (Note that property P20 of SORION makes a similar remark about thesensitivity of relationship objects—objects that solely exist to relate other objects;our axioms about object-orientation do not make separate provision for such objects;however if relationship objects are seen as special cases of objects theorem 14 doesmake a statement about such objects.) We conclude our discussion of compulsory restrictions with a few remarks about restrictions imposed by data structure membership. In an array-like structure it isusually possible to infer the structure of one element from that of another. This in-dicates that all members of the array must have the same sensitivity in an existence protected model. Of course, if the elements of such a data structure are not nec-essarily homogeneous, this requirement may be dropped. We do not address thesensitivity of elements of data structures in detail in this paper, but give one last ex-ample: property P4 of SORION specifies that the sensitivity of a ‘set object’ is theleast upper bound of the sensitivities of the element objects.
The labeling restrictions above raises two questions: 1. The discussion above deals with the sensitivities of classes, objects, variables and methods. What if the model support fewer or additional protectable entities(parameter X2.1); and 2. Is the list of restrictions given complete, or are some restrictions overlooked? The first question is relatively simple: If some of the entities that we used are not labeled explicitly by a model, they must be labeled implicitly and the conse-quences of that labeling taken into account. For instance, if single level objects areused then, although the facets of objects are not explicitly labeled, the intention isthat all facets have the same label as the containing object and facets must conformto the restrictions given. As a slightly more complex example, assume that classesare not labeled for some reason (say, because, they are protected by discretionary se-curity measures and therefore cannot be accessed by subjects not highly trusted). Insuch a case implicit labels have to be derived for classes from the restrictions given;these (implicit) labels will then affect the labels of other entities that are (explicitly)labeled. For example, even if classes and facets of classes are not labeled, secu-rity may be compromised in the following existence protected database: both JOHNand JAMES are instances of the same class; both objects have a CONFIDENTIALsensitivity; JOHN has a TOP SECRET method GETSALARY and a SECRET method GETJOBTITLE, while JAMES has a SECRET method GETSALARY and a TOP SE- CRET method GETJOBTITLE. This is solved by implicitly labeling GETSALARY andGETJOBTITLE in the class (from the explicit labels in the instances) and ensuring that the labels of the methods in the instances conform to the given restrictions.
If a model has more protectable entities than the ones we described, they may ei- ther be special cases of entities that we did consider (such as the relationship objectsmentioned earlier), or axioms will have to be added to describe their relationshipswith other entities and new restrictions derived for them.
The second question is more difficult to answer (and also more critical if we want to trust the any model we design). Given the relative small set of axioms and the factthat we are ony interested in theorems about sensivity levels of related entities, itmay be possible to check that the given restrictions are exhaustive. It may even bepossible to automate the generation of restrictions (or the checking of a given set).
However, this does not solve the problem—how do we know that the axioms coverall relationships? For example, without axiom 8 it is not possible to prove theorem14, and it is not obvious from the problem that an axiom such as axiom 8 shouldbe included. The only solution seems to be to have as many people as possibleproposing axioms and then selecting those applicable to one’s model. Such a bruteforce method is not unheard of in the security community—this method has longbeen used in cryptology.
L(o) ≥ L(class(o)) for every object o ∈ U L( x, o ) = L( x, class(o) ), L(o) for every object o ∈ U andevery facet x of o L(c) ≥ L(d) for every class c ∈ C and every superclass d ∈sup(c) L(c) ≤ L( x, c ) ≤ L( x, d ), L(c) for every class c ∈ C andevery superclass d ∈ sup(c) of c that has a facet x; L( x, d ), L(c) ≤ L( x, c ) ≤ L( x, d ), L(c) if c inherited L(oi) ≤ L( v, ov ) if variable v, ov contains object oi andthe system allows direct manipulation (comparison) of objectidentifiers Table 1: Relationship restrictions for an existence protected model.
L(o) ≥ L(class(o)) for every object o ∈ U L( x, o ) ≥ L( x, class(o) ), L(o) for every object o ∈ U andevery facet x of o L(c) ≥ L(d) for every class c ∈ C and every superclass d ∈sup(c) L( x, c ) ≥ L( x, d ), L(c) where c ∈ C is any class and x afacet that c inherited from a superclass d ∈ sup(c) Table 2: Relationship restrictions for an access protected model.
The restrictions on labeling of related entities described above are necessary be- cause security will be compromised if the restrictions are not enforced; some modelshave additional restrictions because they simplify the model or enhance security insome other way. We briefly look at some of these.
Some models (eg Lunt property 1 and SORION property P2) specify that basic objects (or system objects) must have a system-low sensitivity (Llow). If a modelincludes such a specification, the model has to specify exactly what is meant by basicobjects or system objects. If such a requirement is not included, the system securityofficer and/or the database system have to define the sensitivity of all objects suppliedwith the database.
The relationship restrictions imposed on existence protected models are sum- marised in table 1. The restrictions imposed on access protected models are sum-marised in table 2.
The relevant restrictions from the Lunt model (in our notation) are given in table 3. Property 6 does not appear in that table because it deals with run-time accessrestrictions, which we discuss under the heading dynamic labeling later—see equa-tions 2 and 3. Also note that, since Lunt does not distinguish between a subclass and L(c) = Llow for every system-defined class cL(o) = Llow for every system-defined object o L(c) ≥ L(d) for every class c and every superclass d ∈ sup(c)L(o) ≥ L(class(o)) for every object o L( x, c ) ≥ L(c) for every facet x of any class cL( x, o ) ≥ L(o) for every facet x of any object o L( x, c ) ≥ L( x, d ) for every facet x of any class c where x, c is inherited from a superclass d ∈ sup(c) L( x, o ) ≥ L( x, class(o) ) for every facet x of any object o L( x, d ) ≤ L( x, d ) for every d ∈ sup(c) whenever any classc inherits a facet x from a superclass d ∈ sup(c) L(c) ≥ L( x, d ) → L( x, c ) ≤ L(c) for every superclass d ∈sup(c) of any class c that has a facet xL(o) ≥ L( x, class(o) ) → L( x, o ) ≤ L(o) for every facet xof any object o Table 3: Relationship restrictions imposed by the Lunt model.
an instance of an object, we have interpreted most of the Lunt properties for sub-classes and for instances. Remember that the Lunt model uses existence protectionand, therefore, table 3 has to be compared to table 1. Lunt’s property 2 is identical toour theorems 4 and 9. Nothing in [11] necessitates Lunt’s property 1, and thereforeit falls in the additional relationship restriction category. Lunt’s properties 3, 4 and7 are easily derived from our theorems 5 and 12 , but the converse is not true. Lunt’sproperty 5 is stricter than necessary; for those situations where it is required, it canbe derived from our theorem 12.
Dynamic labeling
This section concerns itself with the flow of authorisation (X3.1), the flow of sensitivedata (X3.2) and the restrictions on such data flows to ensure secrecy despite suchflows (X3.3). Restrictions based on flow of authorisation and flow of informationthat a model introduces to ensure that security will not be compromised, represent ageneralisation of the *-property of the Bell-LaPadula model [1].
The dynamic activities in a system may be modeled by the following simple Here Σ represents the primary accessor, in other words the (probably human) object that sends the original message to the database. The non-terminal M repre-sents a message; the production Σ → M models the message sent by the primary accessor. A message causes a method (of a specific object) to be activated; in thegrammar above ai represents such an active object (or, more precisely method-objectpair m, o ). The list of activities such an active method performs are represented byT . The production M → aiT indicates that a specific method (ai) is activated on re-ceipt of a message, after which that method ‘executes’ a list of activities T . The latterproduction represents a set of productions, each with a different ai for every methodthat may be activated. The production T → M T represents the case where a list ofactivities T consists of sending a message, before executing some more activities;the production T → r represents the activity that terminates execution of the activemethod and sends a reply to the calling method, while the production T → sents the activity that terminates execution of the active method and returns controlto its calling method without sending a reply to the calling method. Note that theintention of these productions is not to generate strings, but to reflect events in thesystem.
Authorisation flow deals with the question whether and how the clearance of a subject is influenced by the method activations acting on its behalf—see X3.1.
Information flow deals with the flow of sensitive information through the system (as messages) and, more particularly, the restrictions that a model may enforce toensure that such information does not flow to somewhere where it is less protected.
As long as an object moves as a unit from one location to another location in the system (probably as a parameter of a message) information will not be compro-mised: The object will still have its original sensitivity label; similarly, the methodsand variables of the object will still have their original sensitivity labels. As anexample, suppose that a SALARY object has a PRINTSALARY method. A subjectthat obtains SALARY from the EMPLOYEE object will still not be able to invokethe PRINTSALARY method if it is not authorised to—even though it obtained the SALARY it cannot do anything with it. The normal encapsulation feature of object- orientation, combined with sensitivity labels, provides very natural protection.
However, if, in the example above, the salary was not encapsulated in a SALARY object, but rather stored as a normal real number, the value would have no naturalprotection once it leaves the EMPLOYEE object. A similar problem occurs anywherewhere an object provides methods that return values of instance variables—when thevalue leaves the protection of the encapsulated object, security may be compromised.
In the final part of this section we consider restrictions that may be dynamically applied to information flow through the system to ensure that, even if such informa-tion is removed from the encapsulated object, it will still not be exposed to unau-thorised access. We assume that information retrieved from a variable or object isas sensitive as the label for that variable or object indicates and that such informa-tion must stay at least as sensitive wherever it might flow in the system. One cannotreasonably make this assumption about information obtained via a sensitive method;another (much less sensitive) method may return the same information. To avoidsuch inconsistencies, we only consider restrictions for information flowing from asensitive variable or sensitive object. One possibility to include the sensitivity ofmethods when considering information flow, is to ensure that any variable is at leastas sensitive as the greatest lower bound of any method that has access to the variable.
We do not investigate this option in the current paper.
Under dynamic labeling we consider three aspects: (X3.1) Messages act on behalf of a subject and therefore the clearance of the mes-
sage depend on that of the subject. A model has to specify how the clearance(or authorisation) of a message is determined.
(X3.2) Messages also carry information—this information may be sensitive, requir-
ing labels. A model has to specify how the sensitivity of a message is deter-mined.
(X3.3) If some of the sensitive information contained in a message is stored in vari-
ables of the receiving object, it must be ensured that an unauthorised subjectcannot now access the information in this object. This can be ensured by eitherre-labeling the object or variable with a suitable label (if the existing labelsare not suitable) or by disallowing information to be saved if the existing la-bels are not suitable. The model should indicate any flow restrictions and anyconventions for re-labeling.
X3.1 Authorisation flow
Consider the grammar above. Which objects should be taken into account when theclearance of a message is determined? The following possibilities exist: 1. Consider only the primary accessor (represented by Σ); 2. Consider all method activations that have been activated since the original mes- sage was sent, but ignore those that have already returned control to their call-ing methods (ie consider all ‘active objects’), including the primary accessor;or 3. Consider all objects on the access path of the request, ie every method acti- vation ai that has been activated since the original message was sent, whetherthat method has terminated execution or not, including the primary accessor.
In SODA the primary accessor determines the clearance of a message (possibility Lunt’s property 6 states (in our notation) where s ∈ S is any subject, m, o is a method of object o that s wants to executeand M is a message sent by s to this effect. It seems from this property that Luntdenotes the clearance of a subject s by L(s); if the clearance of the subject dominatesthe sensitivity of the method to be activated, the subject is allowed to activate it (2).
Further, the message M has exactly the same clearance that its sending subject had(3). It therefore seems that this property indicates that authorisation in the Luntmodel depends only on the primary accessor (possibility 1 above).
SECDB uses the complete access path to determine authorisation (possibility 3 above); however, an individual profile is free to ignore any part of the access path when it determines whether access should be granted. As an example why consid-eration of the entire access path might be useful, consider a stock control system,where the INVENTORY object may only be asked to issue stock (decrease its currentstock level) if a message have previously been sent to the CHECKCREDIT method ofthe requesting object.
In practice, clearances are assigned as follows for the various possibilities: Primary accessor: All messages sent (by any method of any object) on behalf of
the primary accessor have the same clearance—that of the primary accessor; Active objects: All messages sent by a method of an object will have the same
clearance for a given activation of the method; that clearance depends on theclearance of the object-method pair and on the clearance of the message thatactivated the method; and Access path: The clearance of any message sent depends on all objects and methods
involved anywhere previously in the request.
The clearance of messages are influenced by other objects involved in the request if either possibility 2 or 3 above is used. As an example, a model may require thatthe clearance of a message is not higher than the clearance of any object involvedin the request thus far. To generalise this concept, we introduce semantic actions toassociate a clearance attribute M.c with every message sent. These rules are givenin tables 4, 5 and 6. We also associate a sensitivity attribute e.l with every protectedentity e. The possible values of these attributes depend on the underlying model(X1.1); for the time being we assume that it is possible to determine whether messageM is permitted to access entity e given the attribites M.c and e.l. Σ.c denotes theclearance of the primary accessor, ai.c denotes the clearance of an individual methodactivation and the function clear maps the clearance of a message and a methodactivation to their combined clearance.
Table 4: Semantic rules for message clearance based on the primary accessor In addition to the method a secure database model uses, it thus have to specify up to four additional pieces of information: • The format of the clearance attributes (Σ.c, ai.c and M.c); • The format of the sensitivity attribute (e.l); Table 5: Semantic rules for message clearance based on active objects Table 6: Semantic rules for message clearance based on the access path • For which values of M.c and e.l message M may access e; and • How clearances are combined, ie define clear.
Having given rules to determine the clearance of a message we will now consider how the clearance attribute may be used to specify when a given message is autho-rised to access an entity. As stated earlier, this depends not only on the clearanceattribute of the message, but also on the sensitivity attribute of the entity.
The entities that need protection are methods and instance variables. (The object- oriented model does not allow direct access to other entities at all.) In order to model access to instance variables, the following two productions These productions model accessing variables by sending messages to them: M → pximodels writing (‘putting’) a variable xi (where x = v, o for some object o and somevariable v ∈ o). Similarly M → gxi models reading (‘getting’) such a variable xi.
We assume that accessing a variable does not affect the clearance of a message; theseproductions therefore have no semantic actions to modify the clearance attribute; in table 6 it is necessary to add the action M.r := M.c to both productions to indicatethat the clearance does not change. It is now easy to attach semantic actions to theproductions M → aiT , M → pxi and M → gxi to let the message fail when accessrights are insufficient; table 7 contains an example of a complete specification of au-thorisation flow for a model based on explicit levels and using the complete accesspath to determine the clearance of a message.
Table 7: Example of access checking rules for a specific model Some concrete examples of the security attributes denoting the clearance of a subject and the sensitivity of an entity are now given. Note that specific models maydiffer from these examples.
Explicit levels: The clearance attribute will typically be an integer indicating the
clearance level of the primary accessor (Σ.c), individual method (ai.c) or amessage (M.c). The sensitivity attribute e.l for an entity e will also be aninteger. A message M will be allowed to access an entity e if M.c ≥ e.l. Thecombination of two clearance levels may be the greatest lower bound of thetwo, ie clear (M.c, ai.c) = M.c, ai.c .
Access control lists: The clearance attribute will typically be the identity of the pri-
mary accessor (Σ.c), the identity of the individual method (ai.c) or the col-lected identities associated with the message (M.c). The sensitivity attributee.l will be an access control list, giving the identities of subjects permitted toaccess the entity. (The access control list may be given explicitly as a list;SECDB, for example, gives it as a formal grammar.) A message M will beallowed to access an entity e if the identities collected in M.c appear in theaccess control list e.l. The combination of two clearance attributes may be theconcatenation of the two, ie clear (M.c, ai.c) = M.c||ai.c where || denotesconcatenation.
Capabilities: The clearance attribute may contain the capabilities presented by the
primary accessor (Σ.c), the capabilities presented by the individual method(ai.c) or the capabilities collected by the message (M.c). The sensitivity at-tribute e.l may contain the capability necessary to access entity e. A messageM will be allowed to access an entity e if the capability e.l appears in the list ofcapabilities M.c presented by M . The combination of two clearance attributesmay be the union of the two, ie clear (M.c, ai.c) = M.c ∪ ai.c.
As an example SECDB builds a string representing the access path which is sub- sequently used to verify access restrictions. Therefore the ‘clearance’ of the primaryaccessor (Σ.c) and the methods (ai.c) are baggage vectors, representing the identityof the object, the method, the domain (processor) on which the object resides and theintegrity state (or mode) the domain uses while executing the method. These vectorsare concatenated to form strings; the clearance combination function clear concate-nates its arguments, ie clear (M.c, ai.c) = M.c||ai.c. The sensitivity of any entitye ∈ E, represented by e.l, is a profile. The profile is given as a formal grammar; Mmay access e only if M.c is derivable in the grammar associated with e.l.
Although the informal notion of the set of subjects S used thus far is sufficient for our purposes, we are now in a position to formalise it: a subject is any sentential formending with an M obtainable by a leftmost derivation from Σ using the productionsfrom the grammar above: where V represents the alphabet of the grammar. We do not use this definition againin this paper.
X3.2 Sensitivity flow
A message carries information. Some of that information may be explicit valuesin the form of parameters. The mere fact that a message has been sent, is implicitinformation about the contents of the database. This information—both explicit andimplicit—might be sensitive. Nobody can access this information while it is carriedby the message; however, the receiver of the message may assign the informationto an instance variable where it is possible to access it. It is therefore necessary tokeep track of the sensitivity of information contained by a message. We will use thenotation L(M ) to indicate the sensitivity of any message M with the same meaningthat L(e) has for any entity e. Later (see X3.3) we will discuss how the currentsensitivity of a message will be used to prevent information from being assigned to avariable that is not as least as protected as the information contained by the message.
The following rules may be used to keep track of a the sensitivity of a message: 1. The initial message from the primary accessor has low sensitivity (Llow) be- cause it does not contain any information; 2. A method starts execution with the sensitivity of the message that activated it; 3. The sensitivity of the method activation is adjusted whenever it receives a reply after sending a message—the sensitivity is adjusted to the least upper bound ofits current sensitivity and the sensitivity of the reply; 4. All messages sent by a method activation has the sensitivity currently associ- ated with the activation; whenever the sensitivity of the method activation isadjusted, all subsequent messages will be sent with the new sensitivity level;and 5. If the method sends a reply to its calling method, the reply has the last ‘current’ sensitivity of the method activation.
For the purposes of sensitivity flow, access to variables is modeled in terms of mes-sages: writing to a variable is done by sending a message to the variable and readingby sending a message and receiving a response. The sensitivity of the response isnormally the sensitivity of the concerned variable. However, if the object identifier(and not the object as a whole) is retrieved in an existence protected model, the sen-sitivity of the reponse is the least upper bound of the sensitivity of the variable andthe sensitivity of the object identifier (see theorem 14).
The rules are formalised in table 8. The suffix .l again represents the sensitivity of an entity; for example M.l is an attribute representing the sensitivity of messageM . The suffix .u is used to keep track of the sensitivity of information received bya method that was returned as the result of a message. The value llow is the attributevalue that corresponds to the lowest sensitivity Llow. Note that the productions M →gxi (‘get variable xi’) and M → pxi (‘put variable xi’) have been included again tomodel reading and writing of variables.
Table 8: Semantic rules for message sensitivity These rules correspond largely to rules 2.1 to 2.4 of SODA. SODA further re- quires (in its rule 2.3) that the current sensitivity of a method activation must beincreased when a value is written (or “added to a polyinstantiated set”) at a highersensitivity level. This restriction is not necessary: any messages that will be rejectedbecause of this restriction subsequent to such a write may be avoided by reorderingthe statements (messages) in the concerned methods. Of course, nothing prevents amodel from including such a specification; it may be included by changing the se- mantic rule for M → pxi to M.u := xi.l where xi.l denotes the initial sensitivity(see X2.2) of variable xi.
Since Lunt does not distinguish between sensitivity levels and and clearance lev- els, Lunt’s property 6 (see equation 3 above) probably also indicates that the sensi-tivity of a message is the same as the ‘classification level’ (clearance) of the subjectthat sent it. This ‘classification level’ of a message is only defined in that model andthen never referred to again.
An alternative to the rules given above come from [25]: They suggest that it is possible for a method to start execution at the system-low sensitivity (see our rule 2above). This may compromise security: method m1 may access a sensitive variableand based on its value decide to send a message to method m2; if m2 does not accessany variable and send a (non-sensitive) message to m3 then m3 may assign a valuean unclassified variable. If it is known that this sequence of events will only occur ifthe sensitive value accessed by m1 has a specific (range of) values, it is possible toinfer whether that variable does indeed have such a value by examining the unclas-sified variable written by m3, contrary to the information flow restrictions discussedlater (X3.3). Of course, if the composition of methods is not public knowledge (andcannot be inferred) this strategy is viable.
Note that some secure database models partition the set of entities E such that any subject s ∈ S is allowed to access all the entities in at most one partition Ei of E, thatis if s1 ∈ S and s2 ∈ S then either ent(s1) = ent(s2) or ent(s1)∩ent(s2) = ∅. Fur-ther, these models do not transform the subject because of authorisation flow (X3.1)or, if it does transform a subject si into a subject si+1 when a new method joins thecomposite subject, it ensures that ent (si) = ent(si+1). In such a model a subjectcannot cause information to flow to a less protected location and it is unnecessary tokeep track of the sensitivities of messages or to restrict information flow based on thesensitivity of the information. A model with this property is said to support singlelevel subjects.
X3.3 Information flow restrictions
Information contained by a message cannot be accessed directly. However, an objectthat receives a message, may store the received data in instance variables. It is thenpossible that other objects may obtain the information from this object (by sendingmessages to this object). Therefore it must be ensured that sensitive information isnot stored in variables that may be accessed by subjects not authorised to access thesensitive information. This can be done by either ensuring that the variable(s) storingthe sensitive information may only be accessed by properly cleared subjects, or byensuring that the entire object may only be accessed by properly cleared subjects.
Suppose that a message containing sensitive information arrives at an object and that the activated method attempts to write information to a variable. If the sensitivityof either the concerned object or concerned variable dominates the sensitivity of thereceived message no problem occurs: even if sensitive information is stored in thereceiving object will it not be compromised because it is at least as protected as in itsoriginal location. In other words, any message M , accessing any entity e, must beallowed to proceed if L(M ) ≤ L(e)—and, of course, if the subject represented by M is in subj(e). Note that, in the case of a system where the conditions of theorem14 apply (ie existence protection and object identiefiers directly manipulatable), avalue cannot be written to a variable if it will write an invalid value to the variable(according to theorem 14)—steps similar to those when the sensitivity of the messageis too high will have to be taken.
Apart from allowing the message to access the protected entity when the sen- sitivity of the entity dominates the sensitivity of the message, the model may alsodecrease the sensitivity of the variable (or object) if its sensitivity strictly dominatesthat of the message. If the sensitivity is decreased, it must still dominate that of themessage. Further, the sensitivity of the variable (or object) must never be decreasedbelow its initial (inherent) sensitivity (see X2.2).
If the sensitivity of the object or variable to be accessed does not dominate the sensitivity of the received message, security may be compromised. So, if the mes-sage attempts to modify the state of the object, protective steps must be taken. Thefollowing possible strategies exist: 2. Increase the sensitivity of the receiving variable or object; or 3. Polyinstantiate the receiving variable or object.
To formalise the previous remarks we will associate semantic actions with the because information will only be compromised if information is actually written toa variable; information temporarily ‘inside’ an object if a message is just ‘passingthrough’ without modifying the state of the object will not compromise information.
We identify four possible behaviours when a message attempts writing to a variable: Proceed/Reject: If the sensitivity of the message strictly dominates that of the vari-
able, reject the write; otherwise the protection of the variable is adequate andthe write is allowed to proceed. This is accomplished by associating the fol-lowing semantic action with the production M → pxi: Increase sensitivity: Here the sensitivity of a variable (or its containing object) is
increased if the information to be written is too sensitive for the current sensi-tivity of the variable. If the sensitivity is increased, it is increased to that of themessage; this may be done by either setting xi.l or o.l (where xi = v, o ) toM.l. Formally the production M → pxi has the semantic action In an existence protected model it is not possible to change the sensitivity of avariable at will—see theorem 5; it is necessary to change the sensitivity of theentire object. A similar situation exists if single level objects are used. If the level of the entire object is to be adjusted, the then part of the semantic actionhas to be changed: if L(M ) > L(xi) then o.l := M.l, where xi = v, o Note that we are changing the level of a ‘terminal symbol’—on a real system itmeans that the actual security attributes of the related entity must be updated.
Modify sensitivity: Here the sensitivity of the variable is adjusted to reflect the sen-
sitivity of the new value stored in it. This means that the sensitivity of thevariable may be increased or decreased. The only provisos are that the sensi-tivity of the variable must never be decreased below its inherent (initial—seeX2.2) sensitivity, or below the sensitivity of its containing class (see lemma 2).
Put differently, the sensitivity of a variable v, o being written to by a mes-sage M , is changed to L(M ), L(o), L ( v, o ) where L ( v, o ) is the initialsensitivity of v, o . Formally, M → pxi takes the semantic action if L(M ) > L(oj), L (xi) then xi.l := M.lelseif L(o) > L (xi) then xi.l := o.lelse xi.l := xi.l where xi = v, o , L (xi) represents the initial sensitivity of xi and xi.l is thecorresponding sensitivity attribute.
Again, as was the case when sensitivity is increased, it may be necessary toadjust the sensitivity of the entire object.
Note that in the case of structured variables (for example array-like struc-tures) the sensitivity of the entire variable cannot be decreased if a single low-sensitivity element is written. This is not a problem if structured variables areobjects contructed from the individual ‘element’ variables. In such a case onlythe relevant element variable will be re-labeled.
Polyinstantiate: See section 6.1 for a discussion of polyinstantiation.
SECDB takes the option of increasing the sensitivity of the receiving object or vari-able. In SECDB the security profiles associated with the message are attached tothe concerned variable. In effect this means that the variable is re-labeled with theleast upper bound of its original sensitivity and the sensitivity of the message—iethe sensitivity of the variable is ‘increased’ so that it dominates the sensitivity of theactive message.
SODA uses polyinstantiation here—see section 6.1 for a discussion of polyin- stantiation. SODA also specifies a highest sensitivity that may be associated withany given variable; if the sensitivity of the message exceeds this maximum, the mes-sage will also fail (but in this case the database will inform the user that the messagefailed). Formally, if the maximum sensitivity for a variable xi is Lmax(xi), the se-mantic action associated with M → pxi will ensure this.
We stated earlier that either the sensitivity of the concerned variable or the con- cerned object must be increased if the increase sensitivity strategy is used. Corollary 6 restricts strategy 2 for existence protected models: Since the sensitivity of a vari-able may only be increased by increasing the sensitivity of the entire object, it is notpossible to re-label variables; the containing object will have to be re-labeled. In anaccess protected model, it is possible to re-label either the modified variable or thecontaining object; it seems that it is better to re-label the variable, since it minimisesthe risk that an (authorised) user attempting to access another part of the object, willbe denied, only because this variable contains sensitive information. SECDB there-fore re-labels the variable. SODA provides another solution by allowing either theentire object or its instance variables (but not both) to be labeled; in such a model thealready labeled entity will simply be re-labeled.
Modeling in context
Pfleeger [19] lists four stages in the development of a secure system: 1. Modeling is the process where the environment and the concept of security is studied abstractly. This paper is primarily concerned with modeling.
2. In the design stage the means of implementing the model is selected.
3. In the third phase trust is demonstrated. This is done by demonstrating that the design reflects the model accurately and taking steps to ensure that the codecorrectly implements te design.
4. The fourth phase is the implementation stage where the system is constructed.
The later three stages do not represent primary design alternatives for the con- struction of a conceptual model. However they must be considered to evaluate agiven model.
Implementation
Most models do not address implementation. However, an impressive model that isdifficult to implement is not worth much. We briefly address some considerationsleading up to implementation; a thorough study is necessary before detailed com-ments can be made.
According to Pfleeger, design follows modeling and precedes the demonstration oftrust; this section briefly touches design possibilities that makes demonstration oftrust simpler.
As always one should strive to make security related code as small as possible— a small section of code is easier to verify, increasing trust and reliability. This maybe done by building the database on a trusted computing base (TCB); SeaView [12]is an example of a secure relational database making use of a TCB. The databasepartitions information according to its sensitivity and stores it in entities (usuallyfiles) managed and protected by the TCB. If the TCB has already been verified, this provides a quick, reliable way to implement a secure database. It also makes itpossible to port a secure database from one computer to another, if the other supportsa comparable TCB.
Lunt [11] suggested that a secure object-oriented database can be built on top of a trusted relational database. Much work has been done in the field of trusted relationaldatabases which makes this option attractive. Such a database will probably mapclasses to relations, objects to tuples and instance variables to tuple entries. However,we feel that protection of methods is the most exciting possibilty offered by object-oriented databases and, sadly, nothing exists in the relational model to which methodsmay directly be mapped.
• Isolating the security functions and making it as small as possible (as discussed • Using mathematically sound models.
Both these aspects have been mentioned elsewhere in this paper.
Another interesting possibility is a database where the checking may be done statically before objects are included in the database (thereby eliminating the neces-sity for run-time security code and this increasing trust; compare [25]). Consider asecure database model that • Is based on explicit levels, and uses the same label to indicate the clearance and the sensitivity of any labeled entity (X1.1); • Labels (at least) methods and variables (X2.1); • Uses the entire access path to determine the authorisation of a message (X3.1) where the combination of two security attributes (clear) is the greatest lowerbound of the two; • Only allows a message to activate a method if the security attribute of the message dominates that of the method (X3.1); • Only allows a method to read a variable if the security attribute of the method dominates that of the variable (X3.1); and • Only allows such a method to write to a variable if the security attribute of the variable dominates that of the method (X3.3).
In such a model the sensitivity of any message (X3.2) is the same as the clearance(X3.1) of such a message as computed by the rules in table 8. It is therefore notnecessary for such a model to keep explicit track of the sensitivity of a message.
Obviously such a model employs the proceed/reject option to restrict informationflow (X3.3).
The described model will not re-label variables or objects since a value will never be written to a variable that is not already sensitive enough. Therefore the securitylevel of any method will dominate that of all variables that it may potentially read (and not only those that it actually reads during a given activation); further the secu-rity labels of all variables that may potentially be written to will dominate the labelof the method. This makes it possible to statically check the security of any objectthat is added to the database. In this case an underlying monitor is not necessary tocheck access to sensitive information at run-time. It is only necessary to ensure thatthe primary accessor (the human operator) only activates methods this accessor isentitled to—that is • Methods that have a higher security level than the accessor if the method will • Methods with the same security level as the accessor if the method will send a It is relatively simple to implement a view mechanism that will only allow an ac-cessor to ‘see’ methods the accessor is entitled to access. In such a model it is onlynecessary to trust the message passing mechanism; if this mechanism does nothingother than passing messages we can trust the database. However, it needs to be shownthat this model is flexible enough for practical use.
Remaining issues
In this section we briefly look at polyinstantiation, aggregation and inference, discre-tionary access controls and integrity constraints—all aspects that need considerationwhen one defines a secure database model. However, too few models have addressedthem to see any clear alternatives.
Polyinstantiation in an object-oriented database

Source: http://mo.co.za/open/tods.pdf