Proc. of 16th NIST-NCSC National Computer Security Conference, Baltimore, MD, September 20-23, 1993, pages 39-52. REFERENTIAL INTEGRITY IN MULTILEVEL SECURE DATABASES 1 Ravi S. Sandhu and Sushil Jajodia Center for Secure Information Systems & Department of Information and Software Systems Engineering George Mason University,Fairfax, VA 22030-4444 Abstract This pap er studies referential integrityinmultilevel relations with element-level lab eling. Our principal contribution is resolution of an impasse left by previous work in this area. We show that the previous work leaves us with a choice of either accepting referential ambiguity, or severely curtailing the mo deling p ower of multilevel relations. We then showhow to escap e this impasse by eliminating entity p olyinstantiation, while retaining element p olyinstantiation as an option. We also discuss howentity p olyinstantiation can b e securely eliminated. Keywords: multilevel secure databases, referential integrity, p olyinstantiation 1 INTRODUCTION Referential integrity is an imp ortant comp onent of the classical relational data mo del [4]. It is concerned with references from one relation to another. The principal motivation for referential integrity is to prevent dangling references across relations, such as when an employee is assigned to a non-existent department. Consideration of referential integrityinmultilevel relations leads to the realization that it can result in signaling channels for leakage of secret information [3,6, 7]. A multilevel secure relational mo del must cop e with the p ossibility of these channels. The central p oint of this pap er is that prior work on referential integrity has left us with a choice of two undesirable alternatives. We either have referential ambiguity, which results in confusion ab out the meaning of data in relations; or wehave serious limitations on the expressivepower of multilevel relations, such as the inability to classify a relationship b etween unclassi ed entities. Our principal contribution in this pap er is to showhow this unacceptable impasse can b e resolved by building up on the distinction b etween entity and element p olyinstantiation. We argue that entity p olyinstantiation is so contrary to referential integrity that it must b e eliminated. We also demonstrate howentity p olyinstantiation can b e easily prevented, by means of the usual integrity constraints in Database Management Systems. On the other hand element p olyinstantiation can b e tolerated if it is required for purp ose of cover stories, or some similar reason. In other words, element p olyinstantiation can b e available as an option as needed; whereas entity p olyinstantiation should b e eliminated in the data mo del. Note that element p olyinstantiation can b e securely prevented using the technique of [20], if it is not needed in a particular application. The pap er is organized as follows. Section 2 de nes a mo del for multilevel relations with el- ement level lab eling. In this section only individual relations are considered. Section 3 discusses 1 This work was partially supp orted by the U.S. Air Force, Rome Lab oratory under the contract F30602-92-C- 0002. We are indebted to Jo e Giordano for his supp ort and encouragement which made this work p ossible. c 1993 Ravi S. Sandhu and Sushil Ja jo dia the semantics of p olyinstantiation, including the imp ortant distinction b etween entity and element p olyinstantiation. Some of the more subtle asp ects of the de nitions of section 2 are also discussed. Section 4 reviews prior work on referential integrityinmultilevel relations, which leaves us in the impasse mentioned ab ove. Section 5 describ es how to resolve this impasse by eliminating entity p olyinstantiation. Section 6 concludes the pap er. 2 MULTILEVEL RELATIONAL MODEL In this section, we give the basic de nitions and assumptions used with multilevel relations. Our initial fo cus is on individual relations considered in isolation. Consideration of referential integrity, whichinvolves two relations, is deferred until sections 4 and 5. The de nitions and prop erties for multilevel relations given here are conceptually simpler, and di erent in imp ortantways, as compared to previous work on element-level lab eling [6, 11, 12, 13, 15, 16, 17, 19, 20]. The most signi cant di erence is the requirement that there can b e at most one tuple in each access class for a given entity. This gives us the simplicity of tuple-level lab eling, combined with the exibility of element-level lab eling. There are also some other subtle di erences in the precise formulation of various prop erties. The reader is assumed to b e familiar with basic concepts of relational database theory. In analogy to the usual de nition of a relation, a multilevel relation consists of the following two parts. De nition 1 [RELATION SCHEME] A state-invariantmultilevel relation scheme which is de- 2 noted by RA ;C ;A ;C ;:::;A ;C ;TC, where each A is a data attribute over domain D , each 1 1 2 2 n n i i C is a classi cation attribute for A , and TC is the tuple-class attribute. The domain of C is i i i sp eci ed by a range [L ;H ], H L , which de nes a sub-lattice of access classes ranging from L i i i i i up to H . 2 i De nition 2 [RELATION INSTANCES] A collection of state-dep endent relation instances, each of which is denoted by R A ;C ;A ;C ;:::;A ;C ;TC; one for each access class c in the c 1 1 2 2 n n given lattice. Each instance is a set of distinct tuples of the form a ;c ;a ;c ;:::;a ;c ;tc where 1 1 2 2 n n 3 each a 2 D and c 2 [L ;H ], or a =null and c H ; and tc lubfc : i =1:::ng. Note that i i i i i i i i i c must b e de ned even if a is null, i.e., a classi cation attribute cannot b e null. 2 i i We assume that there is a user-sp eci ed apparent primary key AK consisting of a subset of the data attributes A . In general AK will consist of multiple attributes. We also assume that the i relation scheme is itself unclassi ed or, more generally, classi ed at the greatest lower b ound of L , i =1:::n. A tuple whose tuple class is c is said to b e a c tuple. Similarly, a sub ject whose i clearance is c is said to b e a c sub ject. Wenow list four integrity requirements whichwe feel must b e satis ed by all multilevel relations. We call these the core integrity properties.We use the notation t[A ] to mean the value corresp onding i to the attribute A in tuple t, and similarly for t[C ] and t[TC]. i i 2 In many cases it is useful to havean A represent a collection of uniformly classi ed data attributes. This i extension requires straightforward mo di cations to our statements in this pap er, which are all formulated in terms of the A 's b eing individual data attributes. i 3 Note that in previous work [6, 11,12,13,15, 16, 17, 19,20] it has generally b een required that tc = lubfc : i = i 1 :::ng. The main reason for relaxing this requirementto tc lubfc : i =1:::ng is to allowa c-sub ject to sp ecify i the classi cation of individual attributes in a c-tuple. For example, let M and M b e incomparable lab els whose least 1 2 upp er b ound is S and greatest lower b ound is U. We should have some means of allowing a S-sub ject to instantiate a S tuple whose individual classi cation attributes are at, say,U,M , and M . Careful consideration of the up date 1 2 semantics in such situations, leads to the conclusion that a S-sub ject should b e able to instantiate a S tuple, even if the least upp er b ound of the individual classi cation attributes turns out to b e less than S. Prop erty 1 [EntityIntegrity] Let AK b e the apparent primary key of R.Amultilevel relation R satis es entityintegrity if and only if for all instances R and t 2 R c c 1. A 2 AK t[A ] 6=null, i i 2. A ;A 2 AK t[C ]=t[C ] i.e., AK is uniformly classi ed, and i j i j 3. A 62 AK t[C ] t[C ] where C is de ned to b e the classi cation of the apparent i i AK AK primary key. 2 The rst requirement is exactly the de nition of entityintegrity from the standard relational mo del, and ensures that no tuple in R has a null value for any attribute in AK . The second requirement c says that all attributes in AK have the same classi cation in a tuple. This will ensure that AK is either entirely visible, or entirely null at a sp eci c access class c. The nal requirement states that in any tuple the class of the non-AK attributes must dominate C . This rules out the p ossibilityof AK asso ciating non-null attributes with a null primary key. Prop erty 1 is identical to the entityintegrity prop erty of SeaView [17]. Notation. In order to simplify our notation, we will henceforth use A as synonymous to AK , 1 i.e., A and AK b oth denote the apparent primary key.