A belief-consistent multilevel secure relational data model

Information Systems Vol. 24, No. 5, pp. 377-400, 1999

@ 1999 Elsevier Science Ltd. All rights reserved Printed in Great Britain 0306-4379/99 $20.00 + 0.00

Pergamon

PII: SO3M-4379(99)00023-X

A BELIEF-CONSISTENT

NENAD

JUKIC’,

MULTILEVEL SECURE RELATIONAL DATA MODEL+ SUSAN V. VRBSKY~,

BRANDON

ALLEN

PARRISH~,

DIXON~ and BORIS JUKIC~

lDepartment of Information Systems and Operations Management, Loyola University, Chicago, IL, 60611, USA 2Department of Computer Science, The University of Alabama, Tuscaloosa, AL 35487-0290, USA 3School of Management, (Received

George Mason University, Fairfax, VA 22030, USA

23 July 1997;

in final revised for-m 24 June

1999)

Abstract - Multilevel relations, based on the current multilevel secure (MLS) relational data models, can present a user with information that is difficult to interpret and may display an inconsistent outlook about the views of other users. Such ambiguity is due to the lack of a comprehensive method for asserting and interpreting beliefs about information at lower security levels. In this paper we present a belief-consistent MLS relational database model which provides an unambiguous interpretation of all visible information and gives the user access to the beliefs of users at lower security levels, neither of which was possible in any of the existing models. We identify different beliefs that can be held by users at higher security levels about information at lower security levels, and introduce a mechanism for asserting, beliefs about all accessible tuples. This mechanism provides every user with an unambiguous interpretation of all viewable information and presents a consistent account of the views at all levels visible to the user. In order to implement this assertion mechanism, new database operations, such as verify true and verify false, are presented. We specify the constraints for the write operations, such as update and delete, such as select, project,

that maintain belief consistency and redefine the relational algebra union, difference and join. 01999 Elsevier Science Ltd. All rights

Key words: Belief-Consistency,

Multilevel

Secure

Relation,

Relational

Algebra

operations, reserved

Operations

1. INTRODUCTION With the increasing availability of data in many database environments due to such factors as client/server multi-user system architectures and the Internet, it is necessary to restrict the access of users to database information. Access control can be used to ensure the security of the database. The multilevel secure (MLS) relational data model [5,10, 241 provides such access control and is used in environments that exhibit hierarchical propagation of information, such as military institutions, government agencies, hospitals, etc. In a multilevel secure relational data model users and data are classified into various security levels, and a security policy is implemented. The security levels are ordered from highest to lowest and may be organized into a lattice. A typical security policy is to allow users at a certain classification level to see only the data classified at the user’s own level or at a lower classification level. Existing multilevel secure relational data models [4, 9, 10, 17, 221 can present a user with ambiguous information. In some models, while users can see lower level data, they do not have any beliefs about such data. Similarly, users do not know what users at lower security levels believe about data at lower levels. Update operations to the database can cause additional tuples to be created (tuple proliferation) and may present an inconsistent view of the beliefs of the users. Similarly, relational algebra operations, such as the join operation, can produce tuples which are meaningless unless the join is only applied to tuples at the same security level. The main reason for the ambiguity within the existing models is the inadequate semantics of the existing models and the lack of a comprehensive method for asserting beliefs of higher level users about lower level information. In this paper we present an extension of the MLS relational data model which provides the user with an unambiguous interpretation of all visible information, also allowing the user to see the tRecommended

by Gottfried

Vossen

377

378

NENAD

JUKIC etal.

beliefs of lower level users. Neither of these capabilities is possible in any of the existing models, This extended model, which we call the belief-consistent model, can be used in environments where is it useful to document and maintain some or all of the beliefs of users at each security level. We identify different beliefs that can be held by higher level users about lower level information. An original mechanism for asserting beliefs about all accessible tuples, including lower level tuples is developed. This mechanism provides a belief-consistent account of the views at all security levels at the user’s level or below. In order to implement this assertion mechanism, the constraints for the database write operations, such as update and delete, are redefined. Because of the strict semantics provided by this new model, we are also able to define non-restrictive relational algebra operations, such as the join operation, across security levels. The assertion mechanism, write operations, and relational algebra of the belief-consistent model offer several advantages over the existing MLS relational models. First, our model provides instant knowledge about lower level tuples without requiring users to compare tuples, or without having to use information outside of the security labels. The new model provides more knowledge about the beliefs of lower level users and with fewer tuples in some cases. The update procedure eliminates the tuple proliferation problem present in some models, without restricting the scope of an update to a single entity [22]. It also provides added tuple validity, since updates of tuples believed to be false are disallowed. Lastly, the belief-consistent model allows a wider scope of write and relational algebra operations without compromising security. The rest of this paper is organized as follows. In the remainder of this section we provide a description of existing MLS models. In Section 2 we describe the new semantics, and in Section 3 the belief-consistent MLS model based on the new semantics is presented. In Section 4 we describe asserting‘beliefs and the modified update operations for our extended model. The relational algebra for the belief-consistent MLS model is presented in Section 5. Conclusions and future work are discussed in Section 6.

1.1.

Baclcground

Access control [3] ensures that all direct accesses to database objects occur only according to the models and rules fixed by protection policies. There are two different (but not mutually exclusive) ways to enforce access control: discretionary and mandatory. Discretionary access control [3, 81 is based on granting and revoking privileges for the usage of system objects. The privileges are granted (or revoked) to every user separately. Discretionary access control policies allow access rights to be propagated from one user to another. Mandatory access control [3, 61 is applicable on large amounts of information that require very tightly controlled protection, in an environment where the users are grouped into clearances and data are grouped by their classifications. Such environments call for MLS systems. In a mandatory access control policy, access to data is determined solely by the user’s and data object’s membership in security classes. Unlike discretionary access control, mandatory access control also serves as a flow-control policy. This is because multilevel security prevents objects at a given security level from receiving information from other objects that are at a higher security level [21]. MLS models [4, 9, 10, 17, 20, 221 are baaed on the classification of the system elements, where classifications are expressed by security levels. Data objects have security levels and users have clearance levels. The security levels of objects are also known as security labels. A security label can contain one security level or a list of levels [3]. As an example, we can have three possible classifications S-Secret, C-Classified, and U-Unclassified, where S is a higher classification than C and U, and C is a higher classification than U. A security (or clearance) level 11 dominates another level 1s (stated as 11 2 Zz), if 11 is higher than or on the same level as 12 in the partial order of security levels. For example, S 2 C 2 U. According to the Bell-LaPadula [2] simple property, a subject (user) can read a certain object (data) only if the subject’s clearance level dominates the object’s security level. In other words; a subject cannot read an object at a higher or incomparable security level than the subject. A second restriction on multilevel secure databases [2] is the *-property, which states that all writes take place at the subject’s security level or higher. As an example, Figure 1 is a simplified multilevel relation Starships, using the three totally-

A Belief-Consistent

Fig.

MLS Data

1: Starships

Model

Relation

ordered security levels: U-unclassified, C-classified, and S-secret. classified according to its security level (Level). The simple property level S can see all three tuples, while users at level C are allowed users at level U are allowed to see only the first tuple. If a C-level *-property ensures that such a tuple would not be visible at the U the S level. 1.2.

Existing

379

In this example, each tuple is ensures that users at security to see the first two tuples and user elects to add a tuple, the level, but it would be visible at

MLS Models

In order to include multilevel data in most of the MLS relational models [4, 10, 221, a relation is extended with security classifications, and it is called a multilevel relation. The SeaView model [4, 51 was the first formal MLS secure relational database designed to provide mandatory security protection. It extended the concept of a database relation to include security labels. The JajodiaSandhu model [lo, 111 was derived from the SeaView model. It was shown in [ll] that the SeaView model can result in the proliferation of tuples on updates and the Jajodia-Sandhu model addresses this shortcoming. The Smith-Winslett model [22,24] was the first model to extensively address the semantics of an MLS database. The MLR model [17, 181 by Sandhu and Chen is the most recent of the MLS data models. It is substantially based on the Jajodia-Sandhu model and integrates the semantics of the Smith-Winslett model. The Jajodia-Sandhu model provides a formalization of the MLS model as follows. In the Jajodia-Sandhu model, a multilevel relation consists of the following two parts. The first is a state-independent multilevel relation scheme R(A1, Cl,. . . , A,, C,, TC), where each Ai is a data attribute defined over domain Di, each Ci is a classification attribute for Ai, and TC is the tuple-class attribute. The second is a collection of state-dependent relation instances where one such instance exists for each access class c from the set R,(Al,Cl,...,A,,C,,TC), of security levels. Each instance is a set of distinct tuples of the form (ai, cl, . , a,, cn, tc) where tc is the least upper bound of the classes of the attributes in the tuple, and tc indicates the lowest user level that can see the tuple. The instance of a relation at a given access class represents the version of the relation at that class. Using the multilevel relation Starships in Figure 2(a), the relation in Figure 2(a) is also the S-level instance, which is all the tuples in the table. Figure 2(b) illustrates the C-level instance and Figure 2(c) illustrates the U-level instance. In other words, an instance is what users at that level see. S-level users see the relation in Figure 2(a), C-level users see the relation in Figure 2(b) and U-level users see the relation in Figure 2(c). In the Smith-Winslett Model a multilevel database is seen as a set of ordinary relational databases, one database for each level in the security lattice, where all the databases share the same schema. Unlike the Jajodia-Sandhu model, this model does not support classification at Instead, access classes can be assigned only to key attributes the level of each single attribute. and to tuples as a whole. A multilevel relation is characterized by a multilevel relation scheme ,A,,TC), where K is the set of key attributes, each Ai is a non-key attribute, R(K,KC,Al,... and KC is the security levels of the key attribute(s). TC is the security level of the tuple, where Each multilevel relation is mapped according to their TC TC dominates KC for every tuple. into single-level relations at different security levels that have the same schema as the multilevel relation, except that attribute TC is dropped. The Smith-Winslett model adds a semantics based on the concept of belief, where a user sees and believes the contents of the database at its own level, and it sees the data objects at lower security levels. For example, an S user can see S, C and U objects, but it believes only that S

380

NENAD

JUKIC et al.

(a): S-Level Instance

Objective Vessel (K) Micra U Shipping U Vision U U Spying Avenger C . Shipping C

Destination Moon U Saturn U Mars C

TC 1 U U C

(b): C-Level Instance

Vessel (K) 1 Objective 1 Destination Micra U 1 Shipping U ] Moon U Vision U I Swing U 1 Saturn U

( TC 1 U 1 U

(c): U-Level Instance Fig. 2: Starships

in the Jajodia-Sandhu

Model

objects accurately represent the real world situation, and it makes no such assumption about C and U objects. The Smith-Winslett model is also known as belief-based semantics. A belief-based semantics is used in many of the current MLS relational models. In a belief-based model [24] the term belief is used and not knowledge, because the values for the same attributes of the same data object can be different at different levels. Figure 3(a) gives an example of the multilevel relation Starships. S-level users can see S, C, and U-level tuples in Figures 3(b), 3(c) and 3(d), but they believe only in the tuples in Figure 3(b). C-level users can see both C and U-level tuples in Figures 3(c) and 3(d), but they believe only in the tuples in Figure 3(c). Lastly, U-level users can see only U level tuples in Figure 3(d) and they believe in their content. The MLR model [17, 181 represents the latest of the belief-based MLS models. Sandhu and Chen state in [17] that the MLR model is substantially based on the Sandhu-Jajodia model, and also integrates the belief-based semantics of the Smith-Winslett model. The MLR model addresses the semantic ambiguity and operational incompleteness left unsolved in the SandhuJajodia model. The semantic ambiguity problem occurs because, given the absence of an S-level tuple, it is unknown what data is believed by the S-level user. For example, in Figure 2(a) it is unknown if S-level users believe in the vessel Micra. Sandhu and Chen address this semantic ambiguity by allowing upper-level users to borrow lower-level tuples. In the MLR model users see and accept (believe) tuples at their own level and while they can see tuples at lower levels, they must borrow tuples from lower levels if they also want to believe those tuples. (In essence, lower level tuples that are believed are replicated on higher levels and the tc changed to the level of the borrower. To accommodate borrowing, tc is defined as greater than or equal to the least upper bound of the classes of the attributes in the tuple.) Changes to the borrowed-data at a lower level are automatically propagated to higher levels. The UPLEVEL command introduced in the MLR model addresses the operational incompleteness by allowing users to borrow values from different and even incomparable levels.

2. NEW SEMANTICS Within the past ten years, substantial progress has been made in making the MLS model complete, secure and semantically sound. In the MLR model [17, 181, while the authors strive for the elimination of semantic ambiguity, there is still some semantic ambiguity present. Even

A Belief-Consistent

(a):

MLS Data

Multilevel

Relation

1 Vessel (K) 1 KC 1 Objective Avenger ’ 1 C 1 Shipping (b):

Vessel (K) Avenger

1 KC ( C

S-Level

Vessel (K) Micra Vision

KC U U (d):

Fig. 3: Starships

1 Destination ( Venus

1

Destination Mars

Relation

Objective Shipping Spying U-level

1

Relation

Objective Shipping

(c): C-Level

381

Model

Destination Moon Saturn

Relation

in the Smith-Winslett

Model

if borrowing [17] is used to indicate belief of lower level tuples, the meaning of the tuples not borrowed is not clear. It is not known if they are considered false, ‘ C 2 U. Consider the MLS relation STARSHIPS(Vesse1, Objective, Destination) shown in Figure 4, where Vessel is the primary key, with security classifications assigned to the primary key (KC), to every non-key value attribute, and to the tuple as a whole (TC). In Figure 4, ta’indicates the i-th tuple. Users can only see tuples if their user clearance level dominates the TC. In this example, S level users can access information about all tuples stored in the relation (tl - t7). At the same time C and U level users have limited access to the information and can only access tuples t4 - t7. In the existing models, given a lower level tuple, the only way to assert a belief is to have a duplicate tuple at the user’s level. This is illustrated in Figure 4 by tuples t2 and t5; the information in t5 about Atlantis has been duplicated with a TC of S in t2 to indicate it is believed by both S and U-level users. (This is consistent with an example for the MLR model given in [18].) There is also no way to assert disbelief in a tuple in the existing models. For example, suppose that it is believed by S-level users that starship Eagle (described by tuple t7) does not exist; thus, S-level users “disbelieve” tuple t7. There is no way for S-level users to assert this disbelief as part of the S-level instance of tuple t7. The fact that disbelief assertions cannot be incorporated into existing models also makes the interpretation of cover stories more complex than necessary. Consider the starship Voyager. The information about Voyager on the U level is not completely accurate. U-level users are given a cover story of “Training” that hides the real objective of “Spying”. S-level users can interpret t6 as a cover story by noting the inconsistency between t3 and t6. However, without the ability to

382

NENAD

Vessel (K) Avenger Atlantis Voyager Falcon Atlantis Voyager Eagle

KC S U U U U U U

JUKIC etal.

Objective Shipping Diplomacy

Swing Exploration Diplomacy Training Patrolling

Fig. 4: MLS Relation

S U S U U U U

STARSHIPS

attach asserting of disbelief to individual tuples, it is necessary for S-level users to examine multiple tuples to make this determination. An S-level user cannot simply examine tuple t6 and also see that both U and S-level users believe the destination is Mars. Still another problem exists with the lack of explicit belief assertions. Suppose once again that S-level users are aware that starship Eagle (from tuple t7) does not exist, and so S-level users disbelieve t7. It is not. clear whether C-level users also disbelieve t7. Even when a C-level user decides how to interpret this relation, that interpretation is not available to an S-level user. In simple terms, an S-level user does not know “what a C-level user believes or disbelieves.” Seeing what users at lower levels believe can be useful for identifying a security breach. For example, it may be critical for S-level users to see that C-level users also have a disbelief in tuple t7. The above example illustrates three problems: the lack of a facility to assert disbelief in the veracity of a tuple, the inability to interpret cover stories (and tuples true on multiple levels) without requiring the user to examine multiple tuples, and the unavailability of lower level user beliefs. In this paper, we present a belief-consistent approach that provides an unambiguous interpretation In order to unambiguously interof MLS relations, thus addressing the above three problems. pret MLS databases, we first need to identify different beliefs that can be held about information stored in MLS databases. We then show how to augment the MLS model to include specific belief assertions.

2.1.

Interpreting

Accessible Information

We assert that the state of the world cannot simply be constructed by the data at a user’s own level and lower levels [24]. Instead in our belief-consistent model, users are allowed to see not only the tuples, but also see the beliefs of users at lower levels. Our approach conforms to the Smith-Winslett model [24], and therefore, we also distinguish the information in an MLS database as belief. We note that in our framework we do not specify a particular belief policy, such as the one described in the discussion for the MLR model [17]. In such a policy, if no information exists at level I, the level 1 user believes the information at the next lower level. Rather, we include belief assertions to specify integrity constraints [24]; such integrity constraints allow users to indicate how beliefs at higher levels relate to lower levels. In the belief-based MLS model and our belief-consistent model, where TC indicates tuple classification and 1 indicates user’s security clearance, the interpretation of the same level tuple (TC = 1) is straightforward. Every user with a security clearance 1 has the following belief about a same level tuple: “Every attribute value of a tuple from my level correctly represents a property of a real-world entity described by this tuple.” Here, we assume that a real-world entity is an entity that can be uniquely identified within the real world, and is described by one or more tuples in an MLS database as illustrated in Figure 4 by the cover story tuples. As a result, the key in an MLS database is typically an attribute (the primary key) as well as the classification level of that attribute, allowing one tuple per level for an entity. The belief-based MLS models, and all other existing MLS models, do not consider the user’s interpretation of all of the lower level tuples (TC < I). In our belief-consistent model we maintain

A Belief-Consistent

MLS Data

Model

383

that every lower level tuple should and can be interpreted [14, 15, 161. We declare that every lower level tuple can be interpreted by every higher level user as one and only one of the following: i) A lower level tuple can be interpreted by a higher level user as a true lower level tuple. A user on the higher level has the following belief about such a tuple: “Every attribute value of this lower level tuple correctly represents a property of a real-world entity described by this tuple.” In the existing models, due to the lack of a mechanism for asserting beliefs about lower level tuples, the only way to indicate such a tuple is to duplicate it on the higher level. In Section 4 we show how this duplication can be avoided. ii) A lower level tuple can be interpreted by a higher level user as a false lower level tuple. are two kinds of false lower level tuples.

There

(a) If a lower level tuple (TC < 1) represents the same entity as some other higher level tuple (TC = 1), the lower level tuple is interpreted by a higher level user as a false tuple that represents a cover story [19, 241 for the entity represented by the higher level tuple as well. Every user on the higher level 1 has the following belief about the cover story lower level tuple: “Some attribute values of this lower level tuple incorrectly represent a property of a real-world entity described by this tuple.” Cover stories can exist in most of the existing models but they are hard t,o distinguish as such, unless compared by the user to a higher level tuple. In Section 2.2 we show how a cover story tuple can be recognized by a higher level user without comparing it to the other tuples. (b) A lower level tuple can be interpreted by a higher level user as false, even if it is not a cover story tuple. Such a false tuple does not correspond to any real world entity in t,he belief of the higher level user, and hence it is called a mirage tuple. Every user on the higher level has the following belief about the false mirage lower level tuple: “This t,uple represents an entity that does not exist in the real-world.” None of the existing models offers such interpretation to the users, and yet they can all contain such tuples. For example, a Starship relation could contain five unclassified tuples which describe five st,arships that do not exist. S-level users are aware that those five starships do not exist and they interpret them as mirage tuples (whose purpose could be, for example, to boost the morale of the unclassified users). In Section 2.2 we offer a way to interpret a mirage tuple, and in Section 4 we offer a way to assert a belief about a mirage tuple. iii) A lower level tuple can be interpreted by a higher level user as .an irrelevant lower level tuple. Every user on the higher level has the following belief about the irrelevant lower level tuple: “This tuple represents either an existing or a nonexistent entity, and this tuple is not relevant, at this time for my understanding of the real-world.” Such irrelevant information can be thought of as “not verified” information, “either true or false” information, or even as “don’t care” information. We also refer to this kind of tuple aS an untierijied tuple. This information is visible from the higher levels, but the higher levels do not have any assumptions about correct,nrss. Due to the proliferation of information available, it, may be unrealistic to require all tuplcs to be specified as true or false. Even though we assume that a higher level user c.an recognize any lower tuple as a true tuple or false (cover story or mirage) tuple, the higher level users do not have to do so with every lower level tuple. Informally, most, of the information on lower levels is usually true, but higher levels are aware of the possibility that, some of the input on the lower levels could be incorrect, due to the attempts of tampering! or just due to errors by the lower level staff. Not all information may be important in the decision making process on the higher levels. Some information may simply be extraneous for higher level users. If such information is irrelevant, then those tuples can remain unverified. However, if this extended model is applied in an environment where all information must, be int,erpreted, t,his interpretation can be eliminated so that all tuples must be verified and labeled true or false. Similarly, all lower level information could default to all true or all false, unless otherwise asserted by a higher level user. We divide

higher

beliefs and indirectly

level user’s beliefs about lower level tuples into two categories: 76ser asserted beliefs. A belief held by 1 level users that, a lower level tuple is a true

asserted

NENAD JUKIC et al.

384

tuple has to be asserted directly by some user from the level 1. A belief held by 1 level users that a lower level tuple is a mirage tuple representing an entity that does not exist also has to be asserted directly by some user from the level 1. Therefore, a true lower level tuple belief and mirage tuple belief are called user asserted beliefs. A belief held by 1 level users that a lower level tuple is a cover story tuple is derived from the fact that there exists a level Z tuple that represents the same entity as the cover story tuple. A belief held by Z level users that a lower level tuple is an irrelevant tuple is a default belief held for all lower level tuples that are not believed to be true, cover story or mirage tuples. Since cover story belief and irrelevant tuple belief can not be asserted directly by a higher level user, they are called indirectly asserted beliefs. 2.2. Belief-Consistent

Set of Security

LabeZs

The beliefs of true, false and irrelevant are incorporated into the belief-consistent model by expanding the set of security labels associated with the attributes and tuples in the MLS database. We propose a belief-consistent set of labels @cl) which utilizes the idea that security labels can contain a list of levels [7]. The purpose of this expanded set of security labels is to provide a user with a comprehensive interpretation of every part of every visible tuple. When the labels from the belief-consistent set of labels are used, a user is able to deduce his own beliefs as well as beliefs of all lower level users about every visible tuple. Such interpretation is not possible with the regular set of single security labels, such as U, C, and S. For this discussion, we assume totally-ordered security levels, since the additional implementation details that would be necessary in order to accommodate partially-ordered security levels would not contribute to the understanding of the new concepts introduced here. However, the approach we will describe here, can be expanded to include partially ordered security levels. As illustrated in Figure 5, a label contains multiple security levels divided by the symbols: “+” and I’-“. The first letter in the label is denoted in bold and indicates the security level where the tuple or attribute value was inserted. Such,a level is called the primary level of that tuple or attribute. Information is always believed to be true by the primary level users. (Later in this paper, when we say “the level of the tuple” or “tuple from that level,” we are referring to the primary level of the tuple.) The letters that follow the first letter of the label indicate the security levels where users of those levels do have a belief about labeled information, but the labeled attribute or tuple was not created at that level. Such levels are called secondary Zevels. Each security level in the label must dominate the level to its left. Letters that are not preceded by the “-” symbol indicate the secondary levels where the information is believed to be true. The letters following the ‘<-” symbol indicate the secondary levels where the information is believed to be false. The letters that follow the “+” symbol indicate the levels where the information is believed to be true, and the same information is believed to be false at some lower secondary level. If a particular level is not included in a belief-consistent label, then the labeled information is considered to be unverified (irrelevant) at that security level. In the existing models three totally-ordered security levels Ii = U, Z2 = C and Zs = S, would result in three possible security labels: U, C and S. For the same environment, the belief-consistent set of labels is illustrated by Figure 5. The labels provide the user with expanded information about the data at lower levels and the beliefs of users at lower levels. For example, label 2 in Figure 5 indicates unclassified information that is believed true on the secret level, while the classified level views it as unverified information. Label 6 indicates unclassified information that is believed true on the classified level and believed false on the secret level. Label 9 indicates unclassified information that is believed false on the classified level and believed true on the secret level. A user on a specific level can see only the components of the label that describe the levels dominated by the user’s level. Hence, instead of seeing the entire label, a user is able to see only his level’s view of a label. For example, if a tuple is labeled U-S, U is the primary level of that label and a U user sees the label as U. A C user sees the label as U as well. S is a secondary level of that label and an S user sees the label as U-S. If the primary level of a label is higher than the user’s level, the labeled information is not visible to that user. That fact is illustrated by empty entries in the table in Figure 5.

A Belief-Consistent

No. 1 2 3 4 5 6 7 8 9 10 11 12 13

Label L U us u-s UC ucs UC-S u-c u-cs u-c+s C cs c-s S

U view U U U U U U U U U

Fig. 5: Belief-Consistent

t1 t2 t3 t4 t5 t6

Vessel (K) Avenger Atlantis Voyager Falcon Voyager Eagle

KC S US US U US U-CS

Fig. 6: MLS Relation

MLS Data

C view

S view

U U U UC UC UC u-c u-c u-c C C C

U us u-s UC ucs UC-S u-c u-cs u-c+s C cs c-s S

Set of Security

Objective s Shipping Diplomacy US S Spying Exploration U Training u-s Patrolling u-cs STARSHIPS

with

385

Model

Labels

Destination Pluto S Vulcan US Mars us Venus U Mars us Degoba U-CS

I

Belief-Consistent

TC S us S U u-s u-cs

Labels

It) is typically assumed that users at higher levels have more accurate knowledge than users at the lower levels (as a matter of fact this is a basic assumption for the interpretation of security levels). However, the following can occur (perhaps-as a pure coincidence). For example, suppose Enterprise’s destination can be Earth according to U and C-levels, and Mars according to the S-level (which makes destination Earth a cover story according to S). Then suppose a U-level user changes the destination of Enterprise to Mars. At that point, destination Mars is labeled U-C+S. The rejection of such an update would cause a downward information leakage (a covert, channel), and hence, the update must be allowed. In our model a label, such as U-C+S, can provide a mechanism for the detection of inconsistent data and provide additional security, if higher level users must have more accurate knowledge than lower users. The example in Figure 6 illustrates how tuples from the relation in Figure 4 are extended by the belief-consistent set of labels. The interpretation of the tuples on any level is straightforward and it, does not require comparison with other tuples. If all the security labels within a tuple are true on a certain level, the level is included in TC and the tuple is interpreted as true on that level. For example, S-level users believe that tl is true. Users are aware of lower level interpretations as well. For example, S-level users believe that t2 is true and are aware that U level users also believe that t2 is a true tuple (while C-level users interpret t2 as irrelevant). Note that, tuples true on more t,han one level do not have to be duplicated, as was the case for t2 in Figure 4. Tuple t3 is a t,rue tuple on the S-level and an S-level user is also aware that U-level users believe t,he same destination is true. If a security level is not included in one or more of the classifications of the attribute values. then that level is not included in the TC and the tuple cannot be seen by users at that level. This is the case for tuple t3, where level U is not included in the classification of the Objective attribute. U-level users do not see t3, but instead see t5. For a lower level t,uple, if a security level is not

386

NENAD JUKIC et al.

included in any of the classification labels, then that tuple is considered to be irrelevant at that level. For example, tuple t4 is considered to be irrelevant on the S and C levels, and true on the U level. If within a tuple TC is labeled false and KC is labeled true on a certain level, while other attributes are labeled as either true or false, the tuple is interpreted as a cover story on that level. For example, an S level user interprets t5 in Figure 6 as a cover story tuple and is aware that the objective is false, while the destination of t5 is true. S-level users are also aware t5 is irrelevant on the C level. Cover stories are supported by existing MLS models to hide high level information, but cover stories can only be identified by a user if another tuple with the same key (K, KC) is identified. In our model, the user only needs to look at one tuple to identify it as a cover story, because the values of the TC and KC indicate the tuple is a cover story. If all the classification labels within a tuple are false on a certain level, the tuple is interpreted as a mirage tuple on the level. For example, as illustrated by t6 in Figure 6, all attributes including KC are false at levels C and S. While U level users believe t6 is a true tuple, C and S-level users believe that t6 is a mirage tuple. While unclassified users may believe in the existence of such additional vessels, C and S-level users believe that they do not exist. Hence, the belief-consistent labels allow the assertion by C and S-level users that t6 is a mirage tuple. It is impossible in any of the existing models to identify a mirage tuple. We note that in this paper we do not address the implementation issues of the MLS models. In existing MLS models tuples that are believed on multiple levels may or may not be duplicated in storage. If only a single tuple is stored, filtering can be used to produce tuples at lower levels. Regardless of the redundancy in storage, due to the single labels used in existing MLS models, a tuple true on multiple levels is typically presented to the user by multiple tuples. In addition, information outside of the labels must be used, or users must examine multiple tuples to identify cover story tuples. This is not the case for our model due to the belief-consistent labels. As illustrated by Figure 6, in our model a user sees and believes the contents of the database at its own level, and it sees the contents of the database at lower levels, but the user also sees the beliefs of users at lower levels. The user asserts these beliefs through the verify mechanism. This mechanism is implemented by the SQL-like VERIFY command that is described in Section 4. Each level decides what information is credible. Credible information does not have to be replicated if borrowed; instead the belief-consistent labels are changed to indicate it is true. Similarly, information does not have to be overwritten to be deemed as not credible by a higher level. Instead, information that is not credible can be verified by the user as false. This semantics allows us to introduce a mirage tuple. Mirage tuples are not credible, but they cannot be overwritten, because the user at a higher level does not believe that entities represented by such tuples exist. Similarly, our model allows the introduction of the irrelevant tuples, which does not require a user to verify a tuple as true or false. This allows users of our model to differentiate between data that is identified as not credible, through verify false, and that data which has not been verified (irrelevant tuples). Although both our model and the MLR model use a belief-based semantics, our model provides an expanded set of beliefs that can be asserted by the user, while the MLR model is limited to a belief of true in tuples at the user’s level only. In the MLR model if users want to assert a true belief in a lower level tuple, the tuple must be borrowed, so that the tuple is duplicated at the user’s level. However, the meaning of tuples not borrowed is not defined. Our model also allows users to assert disbelief in tuples, which is not available in the MLR model. In our model, there is a clearly defined semantics for asserting beliefs in all tuples at all levels. The expanded set of beliefs provides additional information to the user, such as the beliefs of lower level users in lower level tuples, that is not available in the MLR model. Our semantics also allows for the automatic enforcement of consistency in beliefs at different levels, something that is not available in the MLR model. For example, if a user believes a tuple is true, then any other lower level tuple with different values that represents the same entity must be false, while any lower level tuple with the same values must be true. Our expanded beliefs also change the semantics of the operations to the data, such as updates and joins. For example, in our model we can allow a tuple to refer to a lower level tuple if it is believed true, instead of being limited to referencing tuples at the same level only as in the MLR model. Additional differences between our model and the MLR model are noted in Sections 3, 4 and 5.

A Belief-Consistent

MLS Data

387

Model

3. MLS DATA MODEL CHANGES We now present how the new approach towards complete interpretation of all visible information can be included in the belief-consistent MLS model. We define the belief-consistent MLS model based on existing models such as the Jajodia-Sandhu model, Smith-Winslett model, and the MLR model. The new model includes the belief-consistent set of labels used to provide the complete interpretation of all lower level tuples, and the mechanism for asserting beliefs. We first define several functions that are needed for the model definitions. 3.1.

Function

Definitions

We define a function L. For example,

pi(L)

that

extracts

the primary

level of a belief-consistent

security

label

1 ewise, we define a function called d(L) that = U and pZ(CS) = C. L’k levels of a security label L. For example, sZ(U-C) = {C}, sl(UC-S) = {C,

pl(UC-S)

extracts the secondary S} and sl(C) = 4. If security levels, higher than a primary level, are not represented in a label, users at those levels have no belief about the labeled information (the information is irrelevant on those levels). The levels below the primary level have no knowledge, and therefore no belief, about the labeled information. We also define a function level’s belief Zb(c, L), in order to extract a belief held by a user from a security level c about information labeled by a belief-consistent label. This function extracts the belief of a user from the security level c about information labeled by the belief-consistent label L. For example: Zb(S, U-CS) = -S indicates false information according to an S users’ belief; Zb(C, US) = q5indicates unverified information for C users; and Zb(C, UC-S) = C indicates true information according to a C users’ belief. If a label has only one level (labels 1, 10, and 13 in Figure 5) it is called a simple label. All other labels in Figure 5 are called multi labels. Lastly, we note that we can describe the belief-consistent set of labels with the following regular expression: bcl := (c)+(minus(c)+pZus(c)f)*(minus(c)+)7

* means 0 or more, + means 1 or more, ? means 0 or 1, c indicates a single security level, indicates the “-” symbol and plus indicates the “+‘I symbol. In addition, every single label c on the left, is strictly dominated by every single label c on the right. The definition precludes labels, such as U+C, and instead would represent that label as UC. The number of possible beliefconsistent labels for 71 linearly (totally) ordered security levels, P,, increases with the number of levels according to the following formula: where

minus

P,=

{

if 71 = 1 ifn>l

l

3*(P,_l)+l

In the above formula 3 * (P+l) comes from the fact that every higher level has a choice of 3 possible beliefs: true, false (cover story or mirage): and irrelevant, about any lower level information. The “+l” part comes from introducing a new simple label for every new level. This formula can be rewritten as: p

n

=/-I

2

Given the three security levels, U, C, and S, we have 13 belief-consistent labels as illustrated in Figure 5. We denote the set of belief-consistent labels that are possible for a given lowest security level L and highest security level H as bcZ[L, H], where (H > L). Figure 5 illustrates the possible labels for bcl[U, S]. 3.2.

Model Definition

In order to simplify the model definitions, we will assume a totally ordered set of security levels across the entire relation. However, the definitions can be expanded to include a lattice or sub-lattices of security levels.

NENAD JUKIC et al.

388

Definition 1 (Relation Scheme) A multilevel relation scheme is KC “‘7 A,, C,, TC) where K is the data primary key attribute(s), of K, each Ai is a non-key data attribute over domain Di, each Ci is Ai, and TC is the tuple classification attribute. The domain of KC belief-consistent labels bcZ[L, H].

denoted by IZ(K, KC, Al, Cl, is the classification attribute the classification attribute for and Ci is the set of possible

Definition 2 (Relation Instance) A relation instance, denoted by r(K, KC, Al, Cl,. . . , A,, C,, TC), is a set of distinct tuples of the form (Ic, kc, ~1, cl,. .. ,a,, c,, tc) where each Ic, oi E Di, and k,ci E bd[L,H], and tc is a set of labels defined as follows: For every security a) if there

level I in the range

is a label ICCor ci that

[L, H]:

does not contain

1, then 1 # tc (1 is not included

in tc)

-I E tc (1 is false in tc)

b) else if there

is a label kc or ci in which 1 is false, then

c) else security

level 1 is true in every label ICCand ci, and I E tc (I is true in tc)

In other words, for any tuple, if ICCor at least one ci does not contain the security level E, then that level is not included in tc. The tuple is considered irrelevant on security level I when ICCand all ci’s do not contain 1. Otherwise, if kc or at least one ci indicates a false belief about the attribute value oi at some level, tc indicates a false belief for the tuple on that level. Lastly, if kc and all ci’s indicate a true belief, tc indicates true belief of the whole tuple on that level. For example, if a tuple t has two non-key value attributes and t[KC] = US, t[C,] = UC’S, and t[Cz] = U - C’S, then t[TC] = U - S. The primary level is the first level in the resulting tc label and it indicates the lowest level on which the tuple is believed true. As stated earlier, every tuple must be believed to be true on the level in which it was first inserted and as result, the primary level cannot be false. The primary level of the tuple is the same as the clearance level of the user that inserted it. This is enforced by the insert operation discussed in Section 4.3. However, as discussed in Section 5.4, the join operation can produce spurious tuples which have a false primary level and must be deleted from the result. Similar to the MLR model, we define an MLS relational database as a single relational database where different security level users have their own views of the same relation. In an MLS database that is based on an MLS relational data model, users from different security levels have different views of the same database. We call such views maximum-views in order to distinguish between a regular user created view and a certain security level’s view of all accessible information from an MLS relation. A maximum view (max-view) on a specific level shows all the information that a user from that level is eligible to see, which provides a user from that level with two commodities. First, it gives a user insight into the beliefs about the representation of the particular real-world situation at the user’s own level. Secondly, the max-view also provides complete insight into the beliefs at all lower levels. A max-view on the lower level is a subset of a max-view on the higher level. The max-view on a security level 1 includes all the tuples whose primary level of tuple classification is dominated by that security level. A max-view is similar to the Level Shift operator B[anyone] defined in [24]. As shown in Figure 5, even if a tuple is visible on a given level, some parts of the security labels KC, Ci, and TC may not be visible on that level. Only the parts of the labels that indicate levels dominated by the level of the max-view are visible. Given two classification levels li and lj, the max-view of relation R at level Zi is a subset of the max-view of relation R at level lj, where lj dominates li. In other words, max - viewl, (R) C max - viewl, (R), where li 5 lj. 3.3. Integrity Properties We now present the integrity accommodate the belief asserting properties the only modification of the single label of the existing

properties from the existing MLS models that are modified to mechanism and the belief-consistent set of labels. In some of the is to use the primary level of the belief-consistent label in place models.

A Belief-Consistent

MLS Data Model

389

Entity Integrity Property This property regulates the values and classification of the primary key K. A multilevel relation R satisfies entity integrity if there are no null values in any of the key attributes and the primary level of the non-key attributes dominates the primary level of the key for every tuple. These requirements are more formally defined as follows.

A multilevel

R satisfies

relation

1. Aj E K + t[Aj] # null

entity

integrity

iff, Vt E R:

and t[KC] # null

2. Ai $ K =+ pl(t[Ci]) 2 pZ(t[KC]). The entity integrity property de-facto is the same as in any other MLS model and was originally proposed in the SeaView model. The first requirement is the definition of entity integrity from the standard relational model. The second requirement assures that if a key of a tuple is not accessible, no other part of the tuple is accessible. This eliminates the possibility of presenting users with visible t,uples that have no primary key values. Polyinstantiation

Integrity Property This property defines the real key of an MLS relation, called the apparent key, since more than one tuple can have the same value of the primary key, which is called polyinstantiation [l]. The polyinstantiation integrity property is satisfied if a nonkey attribute value is determined by: the key, the key’s primary level and the primary level of the attribute itself. Secondly, the key, the key’s primary level and the primary level of the tuple classification must determine an attribute’s value and classification. In other words, an instance 7 of a multilevel relation R satisfies polyinstantiation integrity iff for 1 < i 5 n.:

1. K,pl(KC),pl(C,)

-+ Ai

2. K,pl(KC),pl(TC)

+ Ai,Ci.

The first requirement is the modified version (with the primary level included) of the original polyinstantiation integrity required by the SeaView model [4] and later repeated in other models, which defines the real primary key of an MLS relation. As in the Smith-Winslett model, in our model an entity is identified uniquely by its mtity identifier, denoted as EID, that is K, pZ(KC). The second requirement ensures that a relation can have at most one tuple with the same entity identifier per security level. Base Tuple Integrity Property As in the Smith-Winslett model, every entity that is represented in the database must have a base tuple. A base tuple is the lowest level of database tuple where the existence of an entity is asserted. The base tuple must have the same key and the same primary level for the key as the other tuples for that entity. The base tuple must also have the same primary level for: its key, all of its non-key attributes, and its tuple classification. Lastly, none of the attribute values in a base tuple can be null. This last property disallows the possibility of null values representing restricted information. These requirements are expressed formally as follows.

A multilevel

relation

R satisfies

the base tuple property

iff, Vt E R there is a tb E R, such that:

1. t[h’] = tb[K]

2. pl(t(KCI) =

Pl(tb[KC])

3. Pl(tb[KC]) =

Pl(tb[Ci])= Pl(tb[TC])

4. t&h]

# 4.

The base tuple

property

is similar

to the property

required

by the Smith-Winslett

model.

Foreign Key Integrity Property This property regulates the values and classification of the foreign key by requiring the classification of all attributes of the foreign key to be uniform. Either all of the attribute values are null, or none of them are null. Secondly, the attribute classifications of all the foreign key attributes must be the same. If FK is a foreign key of the referencing multilevel relation R, relation R satisfies the foreign key property iff Vt E R:

NENAD JUKIC et al.

390

1. Either VAI E FK, t[Ai] = null or VAi E FK, t[Ai] # null 2. VAi, Aj E FK, t[Ci] = t[Cj]. This property is the same as in the existing MLS models. Referential Integrity Property This property is used to maintain the consistency among tuples of the two relations. Referential integrity assures that where references exist between entities, the related entities actually exist within the database. There are three requirements. The first requirement states the value of a foreign key must be equal to the value of a key attribute in the referenced relation. This precludes the possibility of dangling references for a non-null foreign key. The second requirement requires the primary level of the foreign key to dominate the primary level of the key which it references. This allows only downward references. In the third requirement, the tuple classification of the referenced tuple must be true at the primary level of the referencing tuple. This allows downward references only to tuples believed to be true. Suppose FK is a foreign key of the referencing relation Rl with FKC as its classification, and R2 is the referenced relation with an apparent primary key K. Instances rl of Rl and r2 of R2 satisfy referential integrity iff, Vtl E rl such that tl[FK] # null, and there exists a t2 E r2 such that: 1. tl[FK]

= t2[K]

2. pl(tl[FKC])

2 pZ(t2[KC])

3. Zb(pE(tl[TC]), t2[7T])

= pZ(tl[TC]).

The first two requirements are similar to the requirements of referential integrity from the existing models except that we allow downward references. In the MLR model, a requirement tl[TC] = t2[TC] eliminates referential ambiguity, by allowing tuples to refer to tuples only from the same level. Our belief-consistent model eliminates referential ambiguity by the less restrictive third requirement stated above, which allows a tuple from a higher level to refer to a lower level tuple as long as the lower level tuple is believed to be true on the higher level. For example, there is no meaning if a tuple refers to a lower level tuple that is unverified, or refers to a lower level tuple that is believed to be a mirage tuple or a cover story tuple. However, a tuple can refer to a lower level tuple believed to be true.

3.4. Belief Property We have shown here that integrity constraints can be easily extended to accommodate the beliefconsistent set of labels as a tool for interpreting the lower level information. In the extended model we include a new property, the belief integrity property. This property correlates any user’s belief about a single tuple with that user’s belief about the entity which that tuple represents. For example, if a user believes that a tuple is true, then all other tuples with the same EID must be cover stories. Maintenance of this belief property results in a database that is belief consistent at all security levels. Belief Integrity Property There are four requirements to the belief property. These requirements are defined by the three possible beliefs: true, false and irrelevant. The first requirement states that if a user has a belief about a tuple t which represents a certain entity, the user must have a belief about all other tuples tx that represent the same entity and are visible to the user. Consequently, the second requirement states that if a user does not have a belief about a visible tuple, the user has no belief about any other visible tuple with the same EID. The third and fourth requirements are the extension of the first requirement. The third requirement states that if a user believes that a tuple t which represents a certain entity is a true tuple, the user must believe that all other tuples tz that represent the same entity and are visible to the user, are cover story tuples. Once a user has asserted a belief of true for tuple t, then attributes in any other visible lower level tuple tx (that represents the same entity as t) with the same or different values must be true or false, respectively. (We require the belief in tuple tx at level c to be true, denoted as

A Belief-Consistent

MLS Data

Model

391

(Zb(c,tx[KC]) = c), to preclude a mirage tuple.) And finally, the fourth requirement states that if a user believes that a tuple t which represents a certain entity is a mirage tuple, the user must believe that all other tuples tx that represent the same entity and are visible to the user, are mirage tuples as well. In other words, a multilevel relation R satisfies the belief property iff, Vt E R: 1. if Zb(c, t[TC]) # 4 then Zb(c, tx[TC]) # +,b’t x such that tz[K] and tz E man: - view,(R).

= t[K], txCpZ(KC)] = t[pZ(KC)]

2. if Zb(c, t[TC]) = 4 then Zb(c, tx[TC]) = 4, Vtx such that tz[K] and tx E mnx - view,(R).

= t[K], tx[pZ(KC)]

3. if Zb(c, t[TC]) = c then Zb(c, tx[TC]) = - c and Zb(c, tx[KC]) txbZ(KC)] = tbZ(KC)] and tx E max - view,(R). 4. if Zb(c, t[KC]) = -c then Zb(c, tx[KC]) t[pZ(KC)] and tx E max - view,(R). The belief property

is unique

= -c,Vtx

to our belief-consistent

4. ASSERTING

= tCpZ(KC)]

= c, Vtx such that tz[K]

such that

tx[K]

= t[K],

= t[K], tx[pZ(KC)]

=

model

BELIEFS

In the existing models, the only way for a user to assert belief in a lower level tuple is to replicate the tuple. In the MLR model, a user issues the UPLEVEL command, which duplicates the tuples at, the user’s level. Similarly, in the Smith-Winslett model, the user must, issue an INSERT statement. In our belief-consistent MLS model, users are able to specifically assert their beliefs and disbeliefs through the verify mechanism. The result of the verify mechanism is to make changes to the belief-consistent security labels associated w&h the attributes of the tuples.

4.1. ExpZicit Verification A tuple is always believed to be true by the users on the primary level of the tuple when 1 = pZ(TC), where 1 is the user’s security level. A mechanism for asserting beliefs within a multilevel relation R is necessary in order to document the beliefs of the higher level users about lower level tuples (Vt E R, where pZ(t[TC]) < I) as either true or false. We call the process of asserting beliefs about, lower level tuples the verification process. The verification process can be either explicit (user asserted beliefs) or automatic (indirectly asserted beliefs). The user may explicitly verify a tuple by using the VERIFY command. The automatic verification process is a consequence of upda.te, delete, and explicit verification in certain cases. Tho VERIFY command is used for the explicit verification of a lower level tuple by a higher level user and has t,he following form: VERIFY WHERE

(TRUE

1 FALSE)

R P

where R is an MLS relation, and P is a select condition. Explicit verification occurs when a higher level user recognizes a mirage tuple (VERIFY FALSE) or a true lower level tuple (VERIFY TRUE). As a result of the VERIFY command, aZZthe attribute labels of the tuple(s) are labeled as true (or false). The following restriction is placed on explicit verification. Explicit Verification Constraint A user on a specific level, can not explicitly verify (as true or false) tuples that are already verified on the user’s level, nor can it verify the higher level tuples that are not visible to the user. Vt E R VERIFY (TRUE I FALSE) t 2s accepted ifl: pZ(t[T$]) < c and Zb(c, t[TC]) = 4, otherurisr the operation is rejected.

392

NENAD

JUKIC et al.

Therefore, only non-verified lower level tuples that satisfy the WHERE clause will be explicitly verified by the VERIFY command. In order to satisfy the belief property, for every tuple that was explicitly verified by a user, all other lower level tuples with the same EID must be verified as well. The verification of those tuples is automatic, as a consequence of explicit verification. When a user at level 1 recognizes a non-verified lower level tuple as a mirage tuple, all other lower level tuples that have the same EID must be recognized mirage tuples as well since they represent the same entity. For each non-verified lower level tuple that satisfies the WHERE clause of the VERIFY FALSE command, this command causes the TC, KC, and every Ci to be labeled as false on level 1. In addition to this explicit verification, automatic verification of all other non-verified lower level tuples with the same EID as FALSE at level I is also triggered. When a user recognizes a non-verified lower level tuple tT as a true tuple, all other lower level tuples that have the same EID are recognized as cover story tuples for that entity. If there is more than one non-verified lower level tuple with the same EID that satisfies the WHERE clause of the VERIFY TRUE command, the user must choose only one true tuple TV from among them to be explicitly verified. For each tuple that is being explicitly verified by the VERIFY TRUE command, this command causes the TC, KC, and every Ci to be labeled true at the user’s level 1. In addition to this explicit verification, the automatic verification of all other non-verified lower level tuples with the same EID as the newly explicitly verified tuple is triggered. The TC of those tuples will be labeled as false at level 1. The Ci’s for the attributes that have the same values as the corresponding attributes of tT will be labeled as true at level 1. The Ci’s for those attributes that have different values from tT will be labeled false. Verify Example Suppose

an S user recognizes

Vessel (K) Excelsior UC Excelsior UC The S user issues the following VERIFY WHERE The tuple

TRUE

Objective Exploration U-C C Spying

relation

Destination Degoba UC Degoba UC

Rl as a true tuple.

TC U-C C

command:

Rl Vessel = “Excelsior”

t2 is updated

t2 from the following

and relation

Vessel (K) Excelsior UCS Excelsior UCS

and Objective

Rl changes

= “Spying”

to:

Objective Exploration U-CS Spying CS

Destination Degoba UCS Degoba UCS

TC U-CS CS

The KC, TC and Ci’s of t2 are labeled true on the S level, due to explicit verification. In tl the KC and ~~~~~~~~~~~~ are labeled as true, and TC and Cobjective are labeled as false due to the automatic verification process that was triggered by the explicit verification of t2.

4.2.

Update Operation

As we mentioned earlier, write operations, such as update or delete, can cause automatic verification. These operations can also now take advantage of the fact that all lower level information is interpretable. We give formal descriptions and definitions for all write operations in [12]. Here we demonstrate how the update operation is designed to maintain consistent beliefs at all levels. The SQL-like command for the update operation has the following form: UPDATE SET WHERE

R

Ai = ai[Aj = aj]* P

A Belief-Consistent

MLS Data Model

393

where R is an MLS relation, Ai are attributes from R, ai are values from domains of Ai, symbol * indicates repetition, and P is a select condition which identifies tuples that are to be updated. Updating tuples is restricted by the following constraint. Updating a tuple that is verified false in a specific level is prohibited by a user from that level: kf’tE R, UPDATE t is accepted iff lb(c,TC) # -c. This is because such a tuple is either a mirage tuple, which cannot be used as a base for a new true tuple on the user’s level, or a cover story tuple, which means that there is another tuple with the same EID that is already believed by the user to correctly represent a real-world entity. We believe that this constraint provides added tuple validity. The update operation is regulated according to the update procedure. The formal update procedure is given in [la]. Here we describe the procedure. There are four requirements to the update procedure. R.equirement 1 states that every tuple on the user level that satisfies the WHER.E clause will be updated. Requirement 2 states that for every true lower level tuple that satisfies the WHER.E clause, a new tuple with the same EID will be inserted on the user level due to the update command. Requirement 3 states that if there is an unverified tuple on the lower level that satisfies the WHERE clause, and if there is no other lower level tuple with the same EID, a new tuple with the same EID will be inserted on the user level due to the update command. Requirement 4 states that if there is an unverified tuple on the lower level that satisfies the WHER.E clause, and if there are other lower level tuples with the same EID, a new tuple based on one of the lower level tuples with the same EID will be inserted on the user level, due to the update command. We illustrate how requirements 3 and 4 differ in Section 4.2.2. Update

Procedure

If a user on the security

level c issues a command

to update

1171

MLS relation

I?: Vt E R,, if t satisfies P: 1. ifpl(t[TC])

= c, t will be updated.

2. ifpl(t[TC]) < c and lb(c, t[TC]) = c, a new tuple tn based on t will be inserted while the attribute values of tuple t will not change.

= < c_ and lb(c, t[TC]) = $ and 13ti E R such that ti[K] = t[K] and pl(ti[K]) < c, a new tuple tn based on t will be inserted on th,e c level, while

3. ifpl(t[TC])

pl(t[K]) and pl(t,[TC]) the attribute values oft 4. ifpl(t[TC])

on the c level,

itself will not change.

< c and lb(c, t[TC])

and pl(ti[TC])

= 4 and 3;

< c, the user will choose

new tuple tn based on tu will be inserted

E R such that: ti[K]

a tuple tu from

among

= t[K], pl(ti[K]) all ti’s

(including

on the c level, while the attribute

= pl(t[K]) t),

and a

values of tu itself

will not change.

We distinguish two main categories of updates, for which different rules need to be applied: updating tuples of the same security level as the user level 1 (1 = pl(t[TC])) which is captured by requirement, 1, and updating lower level tuples (I > pl (t[TC])) w h’K h is captured by requirements 2, 3, and 4. This update procedure eliminates the tuple proliferation problem present in the SeaView and Jajodia-Sandhu models; without restricting the scope of an update to a single entity (as in the Smit,h-Winslett model) or limiting updates to user level only (as in the MLR. model). 4.9.1.

UPDATE

of the Same Level Tuples

If the tuple on the same level as the user contains multi labels in KC, TC, or Ci’s, the update can cause changes in other tuples with the same EID. A change of values in the tuple on the user’s level can change classification labels in lower level cover story tuples. Lower level cover story tuples of the updated tuple can have the values automatically reverified (from true to false, or from false t,o true) from the user’s level, for the attribute that is being updated in the tuple on the user’s level. This is illustrated by the following example.

NENAD JUKIC et al.

394

Update Example Suppose for t2.

a C level user updates

Vessel (K) Excelsior UC Excelsior UC

Objective Exploration UC Exploration UC

The C level user issues the following UPDATE SET WHERE

R2 Objective Objective

Due to the update is the tuple t2 on the same EID will no longer believes different objective

4.2.2.

table R2 where tl is a cover story

Destination Degoba U-C Klingon C

TC U-C C

statement:

= “Spying” = “Exploration”

procedure, the only tuple that will change in its value of the Objective attribute level C. However the Objective of the lower level cover story tuple tl with be automatically reverified in order to capture the fact that the C level user that the Excelsior’s objective recorded on the U level is true, since there is a recorded on level C for the same starship. So the result of this update is:

Vessel (K) Excelsior UC Excelsior UC The second tuple by the C level.

the following

is updated,

Objective Exploration U-C C Spying

and the objective

Destination Degoba U-C Klingon C

of the first tuple

TC U-C C

is automatically

reverified

false

UPDATE of the Lower Level Tuples

The update of the lower level tuple always causes the insertion of a new tuple on the issuer level. It also always causes the automatic verification (or reverification), from the user’s level, of the lower level tuple that was being updated, and all other lower level tuples with the same EID. The value of the tuple that is being updated does not change. We allow the update of a previously unverified lower level tuple so that a user does not have to first verify the tuple as true when some of its attributes are believed false. Update

Example

Suppose

an S user decides to update

Vessel (K) Excelsior UC Excelsior UC

Objective Exploration UC Exploration UC

the following

relation

Destination Degoba U-C Pluto c

R3.

TC U-C c

The S user issues the command: UPDATE SET WHERE The result

R3 Objective = “Spying” Vessel = “Excelsior” and Destination

= “Pluto”

is: Vessel (K) Excelsior UCS Excelsior UCS Excelsior UCS

Objective Exploration UC-S Exploration UC-S Spying s

Destination Degoba U-CS Pluto cs Pluto cs

TC U-CS c-s s

The third tuple is created on the S level, and the first two are automatically verified from the S level. If there is more than one non-verified lower level tuple that represents the same entity that is being updated by a higher level user, as stated in requirement 4 of the update procedure, the user is given a choice. This is described in more detail in [12].

A Belief-Consistent

4.3.

MLS Data Model

395

Insert

The insert operation creates a new tuple on the level of the user issuing the insert command. If there is already a tuple with the same EID on the same level as the user, the insert is rejected; instead the user must request an update to that tuple. Suppose a C user decides to insert a tuple into the following relation R4: Vessel (K) Voyager UC-S

Objective Exploration UC-S

Destination Degoba UC-S

TC UC-S

Destination Degoba UC-S Degoba C

TC UC-S C

A C user issues the command: INSERT INTO VALUES which changes

R4 (‘Excelsior’, the relation

‘Spying’,

‘Degoba’)

as follows:

Vessel (K) UC-S Voyager Excelsior C

Objective Exploration UC-S C Spying

where t2 is a new tuple inserted on the C level. The delete operation is defined in a similar manner as the update operation [12]. When a user of the belief-consistent MLS database issues a data modification command, such as update or delete, the command requires other operations to be executed automatically in order to preserve the belief consistency of the database. Such an action is not necessary for the execution of user transactions, but instead is caused by them. Hence, we utilize active rules in order to maintain belief consistency. In [13] we present the set of system-embedded active trusted rules in which events, conditions and actions are expressed through a combination of Starburst-like syntax and system functions for classification label manipulation. For a further discussion of these active rules see [13]. 5. RELATIONAL

ALGEBRA

In this section we describe the relational algebra for the belief-consistent MLS model that includes the belief assertions described in Section 2.1. The select, project, union, difference and join operations are presented. All relational algebra operations for the extended belief-consistent MLS model are defined by using the traditional relational algebra operators from a regular (singlelevel) relational data model. In the definitions in this section 6, n, U , - , and ) x 1 indicate the traditional select, project, union, difference, and join operations, respectively; while the symbols cl’, 7r’, u’ , -’ ) and ) x I’ indicate the newly redefined select, project, union, difference, and join operations, respectively. 5.1.

The Select

Operation

The select operation is used to create a subset of a relation that satisfies a specified select condition. The select, operation is extended to include the belief-consistent security levels and beliefs. If a user of the extended MLS database system from the security level c issues a select statement, the result is as follows: g’a (R) = max-view,(aa (R)) where @ indicates the select condition and R indicates the extended MLS relation on which the select operation is being applied. The select operation returns the maximum-view on the level of the user who issued the command. The select clauses of @ are the same as in traditional relational algebra, but they also include security levels and beliefs, and are of the form: @ = clause(boolean_op clause)* where * means zero or more, boolean_op is AND, OR, and NOT, and

396

NENAD

JUKIC etal.

clause := Ai op Aj 1 Ai op a 1 Ai L b (boolean_op L b)* 1 TC L b (boolean_op L b)* where Ai represents a value attribute (key or non-key) from R, a is a constant, and op is one of the comparison operators (<, =, >, <, 2, or #). TC is the tuple classification label. L is a single label representing a security level (U, C, or S), and b is a belief held by that level (true, false, or nw, where nw means not verified and irrelevant). As an example, suppose an S-level user issues the following select operation of the belief-consistent MLS relation in Figure 6, to choose all tuples with an Objective of Training that are true at level U: AND

~‘Objective=Training

The result

TC

U true

is: Vessel (K) Voyager US

Next, the user selects all tuples and S levels: ~‘Destination=Mars

The result

AND

Objective ’ Training U-S

with Destination

Destination

(s

ti-ue AND

Destination Mars us

TC u-s

of Mars whose destination

is true on both the U

u tr~e)(Starsh@).

is: ’

5.2

(Starships).

Vessel (K) Voyager US Voyager US

Objective Spying S Training U-S

Destination Mars US Mars us

TC S u-s

The Project Operation

The project operation deletes certain columns from a relation. c issues a project statement, the result is as follows:

If a user from the security

level

n:(R) = max-view,(nx(R)) where R indicates an extended MLS relation and X indicates the attribute list of the projected value attributes (key or non-key) from R. No classification attributes are allowed in the X list. The project operation returns the maximum-view on the level of the user who issued the command. In the result of the project operation, all value attributes not specified in the attribute list are deleted together with their corresponding classification attributes.

5.9.

Union

and Difference

Union and difference operations are binary operations, and require the two relations to be union compatible. Two extended MLS relations are union compatible if given two relations R(KR, KCR, Al, CA1 . . . A,, CA,,TCR) and S(Ks, KCs,&,CB1,. . . B,, CB,,TCs), n = m, dOm(KR) = dom(Ks), and dom(Ai) = dom(Bi) for 1 < i < n. By default dom(CAi) = dom(CBi),Vi = 1, ... ,n. If a user from the security level c issues a union or difference statement the result is as follows: R U’ S = max-view,(R U S) R -’ S = max-view,(R - S) where R and S are extended MLS relations. The definitions of the union and difference operations are the same as the definitions of the corresponding traditional binary set operators except that the new operations present the user with the maximum-view of the result on the user’s level. Their simplicity partially stems from the assumption that there is no conflict of information on the same level. In other words, two union compatible relations do not contain contradicting information on the same level (e.g. there will not be two different unclassified destinations for the same starship in two union compatible relations). Even if this (very reasonable) assumption does not hold, in [12, 131, we indicate how active rules can be used to resolve possible inconsistencies in classification labels across tuples.

A Belief-Consistent

5.4.

MLS Data

Model

397

Join

As will be demonstrated in this section, we do not need to restrict the join operation as is the case for other MLS models [17]. The join operation 1x (’ is similar to the traditional join operation in this extended MLS relational model, except that a new TC for the resulting relation must be computed. In addition, the classification attributes may cause spurious tuples which are not true at any security level and these tuples are eliminated. We address only the equijoin operation, but the remaining join operations can be derived from it. When the equijoin is performed the values of the join attributes must be equal in both relations, but their classification labels may be different. The join operation between two extended MLS relations R(KR, KCR, Al, CA1, . . . , A,, CA,, TCR) and S(Ks, KC’s, B1, CB1,. . , B,, CB,, TCs) is defined as follows. If a user from the security level c issues a join statement the result is: RI x /‘S = max-view,(aJc(CPEL(TC(R x 5’)))) where x is the traditional Cartesian product and JC is the join condition. The TC() and CPEL() are functions defined as follows. The TC() function removes the TC fields from both extended MLS relations R and S, and computes the new TC for the resulting as defined in Section 3.2. The CPEL() function is needed to eliminate spurious tuples. Some of the tuples are dropped from the resulting relation according to the following rule. Cartesian product elimination function CPEL(): If a tzlple is not true on at least one security level from which it is visible, that tuple is eliminated from the resulting relation as a result of the Cartesian product. In other words, if for a tuple t label TC is empty (t[TC] = 4) or it starts with a “-I’ symbol (pl(t[TC]) = q4), then t is not verified true on any level and such a tuple does not satisfy the CPEL rule. Such a tuple can not be interpreted by a user on any level as a true tuple, a cover story, a mirage tuple, or an irrelevant lower level tuple. Such a tuple is simply a spurious result of the Carksian product; therefore, it must be eliminated from the resulting relation. We note that a false primary level can occur only as the result of a join, it cannot occur from an insert or update. We now consider the two MLS extended relations, Starships2 and Captains2, and the equijoin operation:

(Starships2

(X]‘Vessel=ship

Captains2).

~:

Starships2

~~

Captains2

Figure 7 illustrates the result of TC(Starships2 x Captains2). Tuples denoted with a # in the TC column indicate those tuples that are not true on any classification level, and hence will be eliminated according to the CPEL rule. For example, the TC for t,uple t16 is computed as follows. The TC is -CS, where: l

Since t,here is a Ci (Destination,

l

Since there

l

And since there

is a Ci (Yrs) that

Armed)

not verified on level U, U is not included

is false on level C, -C is included

is a Ci (Armed,

in TC

in TC

Yrs, Ship) verified false on level S, -S is included

in TC

NENAD JUKIC et al.

398

1 Vessel Hero

Honor 1 Glory Glory Hero

CS

ts

I

CS

t10 tll t12

Mara

ucs ucs ucs CS

UCS

ucs

ucs

Earth Moon Venus Mnrs

cs ucs ucs ucs

t7 t*

Ak-Uld

oe.tination

KC ucs

cs u-cs cs ucs

cs u-cs cs ucs cs u-cs

Earth Moon Venus Mars Enrtb Moon Venus Mars Earth Moon “enua

No

No No Some No

KC

C-P ucs

Joe

“CS u-cs c-s ucs

Joe Joe Joe Joe

No No SOltIe No No No

One

“-cs

ucs ucs ucs ucs

One One Oil= Two

I.-CS u-cs u-cs CS

ucs

Two TWO Two Two Two Two Two Sk Sk

LA- 1 CS

ucs cs

U-OS

cs

ucs ucs ucs ucs ucs

some

ucs

ucs ucs ucs

No NO No SOITICZ

Ship Hero

Yrs

ucs

Six Six

ucs

cs

cs

Hero Hero Hero Honor

I

TC I_-cs

u-cs

u-cs u-cs u-cs c-s

-cs # u-cs -cs # c-s

C-S

c-s c-s

CS CS CS

s s s s

cs CS U-OS U-OS WCS

UC-S UC-S UC-S

u-cs

UC-S

-_I

C-S

-cs #

c-s s s

-s # -s #

u-cs -0s

#

u-cs -cs #

Fig. 7: TC(Starships2x Captainsa)

Vessel

Hero Honor Glory

KC

UCS CS ucs

Destination

Mars Earth Moon

UCS CS U-CS

Armed

No No No

UCS UCS U-CS

Cap

Joe Joe Bob

Fig.8: Starships21 x

KC

UCS UCS UCS

\‘Vessel=Ship

Yrs

One Two Six

U-CS CS U-CS

Ship

Hero Honor Glory

u-cs c-s UC-S

TC

u-cs c-s u-cs

Captains2

Tuple t16 indicates that while U, C and S users all believe in the existence of Vessel Glory and Captain Bob, U-level users are not aware of the Destination Venus. Similarly, both C and S users do not believe Bob has been the captain for six years, and S users also do not believe that Bob is the captain of the Glory. Hence, there is no level that believes t16 is a true tuple and this tuple is eliminated. Using the results in Figure 7 we eliminate the tuples with a # in the TC column CPEL(), and select the condition where Vessel = Ship (qessel=ship ). The results are displayed in Figure 8. We note that while both attributes Vessel and Ship have the same values, they have different classification labels. This is because each attribute played a different role in its relation before the join operation. For example, the first tuple indicates that while U, C and S level users all believe there is a Vessel Hero with Destination Mars, etc., only U level users believe Joe is the Captain of the Hero. In [la] we discuss how these labels can be reclassified to represent the new roles that each attribute plays in the resulting join relation. Queries in the belief-consistent model obey mandatory security, with no read up. The proof is similar to that given in [24] for the Level Shift operator, due to the similarity between Level Shift and our max-views. We have developed proofs of security, soundness and completeness for the belief-consistent model and they appear in [23].

6. CONCLUSIONS In this paper an extended MLS relational model has been presented that is derived from the previous models and based on new semantics. This model enables the unambiguous interpretation of all visible information and gives the user access to the beliefs of lower level users, neither of which was possible in the existing models. Users verify tuples as true or false at their security level and tuples that are unimportant to the user’s level may remain unverified. For the first time, two different types of false tuples are identified: cover stories and mirage tuples. An expanded set of labels is used to represent true or false beliefs at each level. The extended MLS model presented here is the first to include a mechanism for asserting beliefs about all accessible tuples. It was shown -how this mechanism gives users of the MLS database system a natural way of characterizing and interpreting information stored in MLS relations. To complete the new MLS model, write operations and the relational algebra for the new model are included. This model maintains the consistency of beliefs across the security levels when write operations such as insert, update, and delete are used to modify the database. In order to redefine

A Belief-Consistent

MLS Data

Model

399

the update operation, a new set of update rules for the new model was defined, and the updates of the same level tuples were distinguished from the updates of the lower level tuples. This update procedure eliminates the tuple proliferation problem present in other models, without restricting the scope of an update to a single entity or limiting updates to user level only. A new relational algebra was developed, including select, project, union, difference and join. While most of the relational algebra operators remained quite similar to the equivalent operations in the existing models, the definition of the join operation is more complex than in the existing models. However, due to the added semantics, the join operation is much less restrictive than in the existing models. In this model a join is permitted across the security levels. In future work, the MLS model presented in this paper will be further developed. We will describe the computational complexity of our model and possible efficient implementations. (We are currently implementing our model.) The new set of security labels will also be expanded in order to handle partially-ordered security levels. A system generated unique identifier will be added to the model, which will enable including a concept of non-key related cover stories. None of the existing models has addressed such a concept. The possibility of enforcing a hierarchy of non-decreasing truth across totally ordered security levels will be examined. If such a hierarchy is feasible, the model presented here can provide a mechanism for the detection of inconsistent data, which could be very useful in many real-world environments. Acknowledgements

~~ We would

like to thank

the reviewers

for their

insightful

comments.

REFERENCES [l] M.D. Abrams, Security:

Course

D.W. Gambel, S. Jajodia, H.J. Notes. Center for Professional

[2] D.E. Bell and L..J. LaPadula. Report, MITRE Corporation [3] S. Castano,

M. Fugini,

Secure (1974).

G. Martella

[6] D.E.

Denning.

and T.F. Oakland,

and P. Samarati.

Mathematical

Database

Security. IEEE

model. In Proceedings Press (1988).

and Data Security.

Enriching the expressive 7(5):839-841 (1995).

[8] I’. (+rif?iths and B. Wade. An authorization on Database Systems, 1(3):242-255 (1976).

S. Jajodia and R. Sandhu. Toward Denver, Colorado, pp. 50-59, ACM

Addison-Wesley power

mechanism

[9] .J.T. Haigh, R.C. O’Brien and D.J. Thomasen. /I/: Status and Prospects, edited by S. Jajodia (1991). lo]

Recent Mason

Developments in Information University (1996).

Foundations

and

Addison-Wesley Symposium

Lunt. A multilevel relational data model. In Proceedings California, pp. 220-234, IEEE Press (1987).

Cryptography

[7] I,. (long and X. Qian. and Data En,gineerin,g,

Systems:

Computer

[4] D.E. Denning. The sea view security Oakland, California, pp. 218-233, IEEE [5] D.E. Denning and Privacy,

Podell and R. Sandhu. Development at George

IEEE Symposium

labels.

for a relational

IEEE

database

‘ZYansactions systems.

data

model.

Relational (1997).

Model Based

Privacy,

on Security

on the Semantics

on Knowledge

A CM Transactions Database Security Science Publishers

In Proceedings

111 S. Jajodia, and R. Sandhu. Polyinstantiation integrity in multilevel relations. In Proceedings on ,Security and Privacy, Oakland, California, pp. 104-115, IEEE Press (1990). 121 N. .Jukic. A Multilevel Secure Thesis, 1Jniversity of Alabama

and

(1982).

of security

relational

Technical

(1994).

on Security

The LDV Secure Relational DBMS Model. and C.E. Landwehr, pp. 265-279, Elsevier

a multilevel secure Press (1991).

Model.

ACM SIGMOD, IEEE

Symposium

of All Visible Information.

Ph.D.

131 N. .Jukic, and S. Tomic and S.V. Vrbsky. A belief-consistent multilevel secure database through active rules. In Proceedings 20th Intern,ational Conference on Information Technology Interfaces, Pula, Croatia, pp. 335-340, SR(‘E (University Computing Centre), University of Zagreb (1998). 141 N. .Jukic IASTED IASTED

and S.V. Vrbsky. Toward a non-ambiguous multilevel secure relational International Conference on Artificial Intelligence and Soft Computing, ACTA Press (1997).

151 N. Jukic

and

S.V. Vrbsky.

Asserting

beliefs

in MLS relational

models.

databases. In Proceedkngs Banff, Canada, pp. 352-354,

SZGMOD Record, 26(3):30-35

(1997).

161 N. .Jukic and S.V. Vrbsky. Subjects interpretation of objects on lower security levels. In Supplement Proceedings IEEE Symposium on Security and Privacy, Oakland, California, p. 8, IEEE Press (1996).

to the

.17] R. Sandhu and F. Chen. The semantics and expressive power of the MLR data m:del. In Proceedings Symposium on Security and Privacy, Oakland, California, pp. 128-143, IEEE Press (1995).

IEEE

400

NENAD JUKIC etd.

[18] R. Sandhu and F. Chen. The multilevel System Security, 1(1):93-132 (1998).

relational

(MLR)

data model.

tinsactions

on Information

European [19] R.S. Sandhu and S. Jajodia. Polyinstantiation for cover stories. In Proceedings Research in Computer Security, Toulouse, France, pp.307-328, Springer-Verlag (1992).

and

Symposium

on

[20] M. Schaefer, V.A. Lyons, P.A. Martel and A. Kanawati. TOP: a practical trusted ODMS. In Proceedings 18th National Information Systems Security Conference, Baltimore, Maryland, pp. 50-62, National Institute of Standards and Technology,Washington D.C. (1995). [21] G. Smith. Formal methods. Computer Computer Security Solutions (1992).

Security

Reference

Book,

edited by K.M Jackson

[22] K. Smith and M. Winslett. Entity modeling in the MLS relational model. In Proceedings ence, Vancouver, British Columbia, pp. 199-210, Morgan Kaufmann (1992). [23] S.V. Vrbsky and N. Jukic. Security of the Belief-consistency Science, University of Alabama (1998). [24] M. Winslett, on Database

Model. TR-CS-98-0030,

and J. Hruska,

18th

VLDB

Department

K. Smith and X. Qian. Formal query languages for secure relational databases. Systems, 19(4):626-662 (1994).

ACM

Confer-

of Computer Ransactions