A MAC Policy Framework for Multilevel Relational ... - Semantic Scholar

IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 8, NO. 1, FEBRUARY 1996

1

A MAC Policy Framework for Multilevel Relational Databases Xiaolei Qian and Teresa F. Lunt

Abstract | We develop a formal framework of MAC policies in multilevel relational databases. We identify the important components of MAC policies and their desirable properties. The framework provides a basis for systematically specifying MAC policies and characterizing their potential mismatches. Based on the framework, we compare and unify the MAC policies and policy components that are proposed in the literature or imposed in existing systems. Our framework could be used to capture and resolve MAC policy mismatches in the trusted interoperation of heterogeneous multilevel relational databases. Keywords | Inference Channel, Integrity Constraints, Mandatory Access Control, Multilevel Databases, Security Label Semantics, Security Policy

I. Introduction

Multilevel security is a security model that captures the security requirements of military, government, and commercial organizations that are naturally hierarchical and compartmentalized. In such a model, subjects are assigned clearance levels and objects are assigned classi cation levels. These levels together with a dominance relationship between them form a security lattice [3]. Access by subjects to objects is controlled by a security policy , which is an interpretation of the security policy employed in manual systems. The implementation of multilevel security in databases results in multilevel databases . As more multilevel databases are built and connected through computer networks, a wide variety of secure data sources will become accessible. A big challenge presented by this technology is the trusted interoperation of multilevel databases containing data with mismatched security policies. Providing trusted interoperation of multilevel databases not only makes it possible to reliably share data in isolated military and civilian databases, but also increases users' con dence and willingness in such sharing. A. Problem As a prerequisite to the trusted interoperation of multilevel databases containing data with mismatched security policies, the security policies of component databases, as well as the potential mismatches between them, have to be precisely characterized. The security policy of a multilevel This work was supported by the U.S. Department of Defense Advanced Research Projects Agency and the U.S. Air Force Rome Laboratory under contracts F30602-91-C-0092 and F30602-92-C-0140. An extended abstract of this paper, titled \Toward A MAC Policy Framework", appeared in Proceedings of the Ninth IFIP WG 11.3 Working Conference on Database Security, pages 181{198, 1995. Xiaolei Qian is with Computer Science Laboratory, SRI International, 333 Ravenswood Avenue, Menlo Park, CA 94025; email: [email protected]. Teresa F. Lunt is with ARPA/ITO, 3701 North Fairfax Drive, Arlington, VA 22203-1714; email: [email protected].

database can be very complicated, ranging from high-level speci cations such as the type of access control (mandatory or discretionary) or the kind of model (noninterference or Bell-LaPadula), to designer's belief or preferences such as whether polyinstantiation is allowed, to low-level implementation decisions such as the number of levels allowed in a lattice. A formal policy framework is needed within which security policies could be characterized and compared [8]. As a rst step in this direction, we propose a formal framework for an important class of security policies: the mandatory access control (MAC) policy. It has been widely accepted that a MAC policy consists of four components: a set of subjects, a set of objects, a lattice, and a mapping that associates levels in the lattice to subjects and objects [11]. This works ne with multilevel operating systems, because objects such as les do not carry semantics. For multilevel databases where data carry semantics, the same mapping of levels to objects such as elements in tuples could have completely dierent meanings [26]. For example, consider a relation SMD(Starship, MId, Destination). A secret label on element Rigel of tuple (Enterprise, 101, Rigel) in SMD could mean that the fact \Enterprise is going to Rigel" is secret, or the fact \some starships are going to Rigel" is secret, or even the word \Rigel" is secret. This confusion suggests that something critical is missing with the traditional formulation of MAC policies in multilevel databases, namely the semantics of object labels. This problem is crucial in the trusted interoperation of multilevel databases. For example, if the secret label on Rigel means that the fact \some starships are going to Rigel" is secret in database A, and means that the word \Rigel" is secret in database B, then unclassi ed subjects could query all destinations in database A and obtain \Rigel" through interoperation with database B. The canonical MAC policy for federated databases proposed in [18] does not solve this problem. The formulation of a MAC policy in a multilevel database often includes some constraint policies, such as the labeling policy of Seaview [13] and the classi cation constraints of LDV [7]. Constraints are the most important means of specifying data semantics. However, the MAC policies in existing multilevel databases provide neither a precise de nition of constraint validity nor an ecient mechanism of constraint enforcement. In fact, it has been argued [1], [14] that integrity enforcement is in fundamental con ict with secrecy enforcement: no multilevel databases could simultaneously satisfy both integrity and secrecy requirements. An important characteristic of MAC policies is the upward information ow in the lattice, which indicates the

2


believability of low data at high levels. For multilevel operating systems where objects do not carry semantics, low data are always believed at high. For multilevel databases where data carry semantics expressed by constraints however, low data could contradict high data. For example, if we require that high SMD tuples have unique MId elements and (Enterprise, 101, Rigel) is a high tuple in SMD, then the low tuple (Enterprise, 102, Rigel) in SMD could not be believed at high. This problem suggests that the formulation of MAC policies in multilevel databases should provide means to constrain upward information ow. Constraints also bring about the danger of inference channels. Inference channels could be obtained by observing the behavior of a database in enforcing the constraints.1 In other words, the result of a low update could violate some constraints when combined with high data, but prohibiting the low update would enable the low subject to infer the existence of relevant high data. For example, consider another relation MT(MissionId, Type). If we require that every high MId element in SMD refers to a high or low MissionId element in MT, then prohibiting the deletion of a low MissionId element referred to by a high MId element would enable low subjects to infer the existence of the high MId element. Thus the formulation of MAC policies in multilevel databases should provide means to detect and remove such inference channels. Existing research on security policies has focused on using rst-order logic to specify, analyze, and enforce the security requirements of an application (see for example [15], [16], [25], [28]). Security policies are formulated in terms of a set of subjects, a set of objects, and a set of rules governing the various modes of access of subjects to objects. There are several problems associated with applying this approach to MAC policies. The objects are usually the physical containers of data rather than the semantics of data, and are often too coarse in granularity (e.g., buildings in [15] and les in [16]). Moreover, rst-order logic is not expressive enough to capture the upward information

ow in the lattice, or the dynamic behavior of a database in constraint enforcement. In addition, no methods are available to translate the logical statements in security policy speci cations to the labels and constraints in multilevel databases. B. Overview of The Paper We present a formal framework for MAC policies in multilevel relational databases. The main contributions are the identi cation of important components of MAC policies and their desirable properties, the provision of a basis for systematically specifying MAC policies and characterizing their potential mismatches, and the uni cation of MAC policies and policy components that are proposed in the literature or employed in existing systems. 1 Because inference channels involve system behavior, in many cases the mechanisms could also be used as covert channels between cooperating malicious high and low subjects. However, we concern ourselves here only with undesired inferences through such mechanisms, which do not require either a high \sender" or that the low \receiver" be malicious.

In Section II, we describe our framework and identify the components of MAC policies. Besides the standard components of such policies, we identify three new components| an interpretation policy, a view policy, and an update policy|as essential for multilevel relational databases. In Section III we introduce the (single-level) relational model and the notion of atomic decomposition. In Section IV we formally de ne the multilevel relational model with tuplelevel labeling. In Sections V through VII, we investigate in detail the three most important new components of our policy framework. In particular, Section V de nes an obvious interpretation policy for multilevel relational databases with tuplelevel labeling, through which a natural interpretation policy for multilevel relational databases with element-level labeling is then formulated. Section VI analyzes problems with existing view policies, identi es desirable properties of such policies, and presents a view policy that satis es these properties. Section VII analyzes problems with existing update policies, identi es desirable properties of such policies, and presents an update policy that satis es these properties. Finally, Section VIII oers some concluding remarks and a brief discussion on using our policy framework to capture and resolve the MAC policy mismatches in the trusted interoperation of heterogeneous multilevel databases. II. A Policy Framework

We develop a model-theoretic foundation of multilevel relational databases. We then present a framework of MAC policies based on the foundation, and identify the components of our framework. A. A Model-Theoretic Formulation We distinguish between the actual world and a perceived world . A perceived world is a view of the actual world as perceived by a group of users. Information in a perceived world is the knowledge (of a group of users) of the truth value of a statement about the actual world [17], which could be either an elementary fact such as \Enterprise is on mission #101 to Rigel" or a general law such as \starships have unique missions". A (single-level) relational database captures information in a perceived world|the view of the actual world as perceived by users of the database. Elementary facts are represented as tuples in relations, and general laws are represented as integrity constraints. For example, the elementary fact \Enterprise is on mission #101 to Rigel" could be represented by the tuple (Enterprise, 101, Rigel) in relation SMD, and the general law \starships have unique missions" is represented by a functional dependency SMD: Starship ! MId. A standard model-theoretic formulation of a relational database is to interpret relation names as predicates, integrity constraints as axioms in a rst-order theory, and relations as forming a rst-order structure of the theory [17]. A database is valid if the structure is a model of the theory. For example, the tuple (Enterprise, 101, Rigel) in

QIAN AND LUNT: A MAC POLICY FRAMEWORK FOR MULTILEVEL RELATIONAL DATABASES

3

relation SMD is interpreted as a tuple in the assignment view constraint SMD: Starship ! MId mapped to c by to predicate SMD, and the functional dependency SMD: is interpreted as the axiom Starship ! MId is interpreted as the axiom (variables are SMDc (x; y1 ; z1 ) ^ SMDc (x; y2 ; z2) ! y1 = y2 universally quanti ed) in theory T c, and the labeling constraint SMD: Starship SMD(x; y1 ; z1 ) ^ SMD(x; y2 ; z2) ! y1 = y2 : ! MId is interpreted as the axiom A multilevel perceived world is a family of perceived l1 l2 worlds organized into a lattice. A perceived world at a (8l1; l2 2 L)(SMD (x; y1 ; z1 )^SMD (x; y2 ; z2 ) ! y1 = y2 ) level in the lattice is the view of the actual world as per- in A. ceived by subjects at that level.2 Information in a multilevel perceived world is either information in the perceived B. MAC Policy worlds or knowledge of relationships between the perceived We restrict ourselves to multilevel relational databases worlds. The former could be either a classi ed elementary whose MAC policies have the simple security property and fact such as \it is top-secret that Enterprise is on mission the -property of the Bell-LaPadula model [11], which en#101 to Rigel", or a classi ed general law such as \con sure that information does not ow downward in the latdential starships have unique missions". The latter could tice. be a general law on classi cation such as \starships classi The Simple Security Property. A subject is al ed at all levels have unique missions". lowed a read access to an object only if the former's A multilevel relational database captures information in clearance level is identical to or higher than the latter's a multilevel perceived world. It consists of a relational classi cation level in the lattice. database, whose integrity constraints are called view con The -Property. A subject is allowed a write access straints , together with a labeling function and a set of to an object only if the former's clearance level is idenlabeling constraints . The labeling function maps every obtical to or lower than the latter's classi cation level in ject in the database|relation, attribute, tuple, element in the lattice. a tuple, view constraint, etc.|to a (possibly empty) set of Our formulation of a MAC policy in a multilevel relalevels in the lattice. The database and the labeling function tional database has eight components: together represent the family of perceived worlds, and the 1. a lattice of levels, labeling constraints represent the general laws on classi2. a set of subjects, cation. For example, the tuple (Enterprise, 101, Rigel) 3. a set of objects, mapped to ts by represents the classi ed elementary 4. a mapping of subjects and objects to levels, fact \it is top-secret that Enterprise is on mission #101 5. a set of labeling constraints, to Rigel". As a view constraint, the functional dependency 6. an interpretation policy, SMD: Starship ! MId mapped to c by represents the 7. a view policy, and classi ed general law \con dential starships have unique 8. an update policy. missions". As a labeling constraint, the functional depen- The ve components together correspond to the tradidency SMD: Starship ! MId represents the general law on tional rst formulation of MAC policies in multilevel relational classi cation \starships classi ed at all levels have unique databases. missions". An interpretation policy maps a multilevel relational The above observation suggests a model-theoretic for- database to a multilevel theory and a multilevel structure mulation of multilevel relational databases as follows. A of the multilevel theory. Through this policy, the super l multilevel theory is a triplet (L; fT gl2L ; A): cial syntactic dierence in object labels is abstracted away, 1. L = (L; ) is a lattice where L is a set of levels and and the semantic dierence hidden in object labels is made is the dominance relation , precise. As a consequence, the interpretation policy makes l 2. fT gl2L is a family of rst-order theories|one for ev- it possible to compare the semantics of multiple MAC poliery level in L, each of which representing the view cies. constraints that are mapped to a particular level, and A view policy is a speci cation of the upward information 3. A is a collection of axioms representing the labeling ow|believability of low data at high levels. For every constraints. level, view constraints We use to denote the strict dominance subrelation, and believable at that level.at that level are enforced on data to denote the transitive closure of . A multilevel struc- An update policy consists of a set of updates and a speciture of the multilevel theory is a family of rst-order struc- cation of the enforcement of labeling constraints on visible tures fM l gl2L where M l is a structure of theory T l. in performing the updates, such that inference chanFor example, the tuple (Enterprise, 101, Rigel) in rela- data nels are eliminated in the enforcement. tion SMD mapped to ts by is interpreted as a tuple in In the rest of this paper, we investigate the last three the assignment to predicate SMDts in structure M ts, the components of our policy framework, using examples from multilevel relational databases based on the lattice in 2 These perceived worlds dier, because the actual world allowed to be known and understood diers for subjects at dierent levels. Fig. 1.

4


> m1

m2

? Fig. 1. A Lattice

III. Relational Model

Before de ning the multilevel relational model, we need to de ne the (single-level) relational model. Following the practice of most existing approaches, we consider the relational model [30] extended with two important classes of constraints: key-based functional and referential dependencies. We then develop the technique of atomic decomposition, and characterize the information content of relational databases using the technique. The results obtained here will be used repeatedly in the rest of the paper.

Let D be a (possibly in nite) set of values. A tuple over attributes X is a partial mapping t[X ]: X 7! D that assigns values from D to attributes in X . For attribute A 2 X , t[A] denotes the value assigned to A by t[X ], and t[A] = 6 denotes that t[A] is unde ned.3 For attributes Y X , t[Y ] denotes the partial mapping whose domain is restricted to attributes in Y . For tuple t over X , t[X ] = 6 denotes that t is empty: t[A] = 6 for all attributes A 2 X ; and t[X ] 6= 6 denotes that t is total: t[A] 6= 6 for all attributes A 2 X . A relation r over relation scheme R[X; K ] is a set of tuples over X . For attributes Y X , r[Y ] denotes the set of tuples t[Y ] where t 2 r. Relation r satis es the key integrity property if: 2.1 for every tuple t 2 r, t[K ] 6= 6 , and 2.2 for every pair of tuples t; t0 2 r, t[K ] = t0 [K ] implies t = t0 . In other words, tuples with the same primary key are identical. A database b over schema (R; C ), where R = fRi [Xi ; Ki ]g1in , is a family of relations fri g1in , where ri is a relation over Ri [Xi ; Ki ]. It satis es the referential integrity property for referential dependency Ri [Y ] ,! Rj in C and tuple t 2 ri if: 3.1 either t[Y ] = 6 or t[Y ] 6= 6 , and 3.2 if t[Y ] 6= 6 then there is a tuple t0 2 rj such that t[Y ] = t0 [Kj ]. In other words, every non-null foreign key refers to an existing primary key. D is the universe of b. Below is a database over the schema of Fig. 2 that satis es the key and referential integrity properties.

A. Basic Notations Let U be a nite set of attributes . If X; Y are subsets of U , then XY denotes the union of X; Y . If A 2 U , then XA denotes X fAg. A relation scheme (in Boyce-Codd Normal Form) R[X; K ] is a set of attributes X U named R with nonempty primary key K X . A database schema Starship Mission Destination is a pair (R; C ), where R = fRi [Xi ; Ki ]g1in is a family of relation schemes and C is a set of key-based referential Enterprise 101 Rigel dependencies : Voyager 102 Talos 1.1 Every referential dependency in C has the form Discovery 103 Rigel Ri [Y ] ,! Rj , where 1 i; j n, Y Ki or Y X ? Ki , and jY j = jKj j. Y is a foreign key in relation scheme Ri to relation scheme Rj . MissionId Type 1.2 Distinct foreign keys in the same relation scheme 101 spy are disjoint. In other words, Y = Z or Y \ Z = ; for 1 i; j; k n and Ri [Y ] ,! Rj ; Ri [Z ] ,! Rk in C . 102 explore For relation scheme Ri [Xi ; Ki ] in R and attribute A 2 Xi , 103 mine A is a nonkey attribute if A 62 Ki and A 62 Y for any foreign key Y in Ri . Fig. 2 shows a schema with two relaFor Y X , the total projection of relation r[X ] to Y , tion schemes SMD and MT, where boxes represent relation denoted as Y r[X ], is de ned as the set of tuples t[Y ] such schemes, attributes to the left of double lines form primary that t [ Y ] 6= 6 and t[Y ] 2 r[Y ]. keys, and arrows between boxes represent referential dependencies. B. Atomic Decomposition Every tuple in a database represents an elementary fact. SMD Often, the elementary fact represented by a tuple is a conStarship MId Destination junction of several smaller elementary facts. For example, tuple (Enterprise, 101, Rigel) represents the elementary MT MissionId Type

Fig. 2. A Schema

3 Null values say that some elementary facts either don't exist or are missing from the database. Because a database is not a part of the perceived world that the database tries to capture, null values do not represent elementary facts.


fact \Enterprise is on mission #101 to Rigel", which is the conjunction of two smaller elementary facts \Enterprise is on mission #101" and \Enterprise goes to Rigel". Let B = (R; C ) be a schema where R = fRi [Xi ; Ki ]g1in . The atomic decomposition of B is a schema Ba consisting of the following set of relation schemes Ra : RiK [Ki ; Ki ] for every Ri [Xi ; Ki ] in R, RiY [Ki Y; Ki ] for every Ri [Xi ; Ki ] in R and foreign key Y in Ri where Y Xi ? Ki , and RiA [Ki A; Ki ] for every Ri [Xi ; Ki ] in R and nonkey attribute A 2 Xi ? Ki ; and the following set of key-based referential dependencies Ca: RiY [Ki ] ,! RiK and RiA [Ki ] ,! RiK for every RiK [Ki ; Ki ]; RiY [Ki Y; Ki ], and RiA[Ki A; Ki ], RiK [Y ] ,! RjK for every foreign key Y in Ri to Rj where Y Ki , and RiY [Y ] ,! RjK for every foreign key Y in Ri to Rj where Y Xi ? Ki . In other words, the atomic decomposition of a schema consists of, for every relation scheme, a relation scheme for the primary key, a relation scheme for every foreign key that is not in the primary key, and a relation scheme for every nonkey attribute. Fig. 3 shows the atomic decomposition of the schema of Fig. 2. S

I

Starship

M Starship MId

D

MissionId

T

Starship

Destination

MissionId

Type

Fig. 3. An Atomic Decomposition of Schema

From every database b over B we could construct a unique database ba over the atomic decomposition Ba of B as follows. From every relation ri 2 b over Ri [Xi ; Ki ] in B, we construct relations riK = K ri ; riY = K Y ri , and riA = K A ri in ba over RiK ; RiY , and RiA , respectively. We can show that B and its atomic decomposition Ba are semantically equivalent [20]. Notice that every tuple in b is in general broken into several smaller tuples in ba . Therefore every elementary fact captured by b is equivalent to a conjunction of perhaps several smaller elementary facts captured by ba. Notice that the atomic decomposition of a database does not contain 6 (by the de nition of the total projection operator ). This implies that null values in a database do not represent elementary facts, which coincides with our intuition. Furthermore, the atomic decomposition of B into Ba is the nest possible decomposition, in the sense that every tuple in ba represents an atomic elementary fact whose further decomposition leads to loss of information. For example, tuple (Enterprise, 101) represents the elementary fact i

i

i

5

\Enterprise is on mission #101", while tuples (Enterprise) and (101) represent the elementary facts \there is a starship named Enterprise" and \there is a mission #101", respectively. The conjunction of the latter two is not equivalent to the former. C. Information Content Given databases b and b0 over schema B with relations fri g1in and fri0 g1in , respectively, b [ b0 denotes the database fri [ ri0 g1in over the same schema. Database b is a subdatabase of b0 , denoted as b b0 , if ri ri0 for 1 i n. Database b0 is more informative than b, denoted as b v b0 , if the atomic decomposition of b is a subdatabase of the atomic decomposition of b0. In other words, b0 is more informative than b if every atomic tuple in b is also an atomic tuple in b0 . Let v; v0 be either values in D or 6 . We de ne the operators ; on v; v0 as follows, where v v0 computes the noncon icting information in v; v0 , and v v0 computes the information in v and the noncon icting information in v0 :

8 < v if v = v0 or v0 = 6 0 v v = : v0 if v = 6 6 otherwise v if v 6= 6 v v0 = v0 otherwise:

Let t; t0 be tuples over X . We de ne the operators ; on t; t0 as follows, where t t0 computes the noncon icting information in t; t0 , and t t0 computes the information in t and the noncon icting information in t0 :

8 < t if t = t0 or t0 = 6 0 t t = : t0 if t = 6 6 otherwise t if t 6= 6 t t0 = t0 otherwise:

Let B = (R; C ) be a schema where R = fRi [Xi ; Ki ]g1in . Given relation ri over Ri [Xi ; Ki ] and tuples t; t0 2 ri , we de ne the operators ; on t; t0 as follows, where t t0 computes a tuple over Xi that contains the noncon icting atomic tuples in t; t0 , and t t0 computes a tuple over Xi that contains the atomic tuples in t and the noncon icting atomic tuples in t0 . Suppose that Z is either Ki , or a foreign key Y in Ri where Y Xi ? Ki , or a nonkey attribute A 2 Xi : (t t0 )[Z ] = t[Z ] t0 [Z ] (t t0 )[Z ] = t[Z ] t0 [Z ]: Given two relations ri ; ri0 over Ri [Xi ; Ki ], let ri ri0 denote the following relation over Ri [Xi ; Ki ], which computes the noncon icting information in ri ; ri0 :

ft t0 jt 2 ri ^ t0 2 ri0 ^ t[Ki ] = t0 [Ki ]g [ftjt 2 ri ^ :(9t0 )(t0 2 ri0 ^ t0 [Ki ] = t[Ki ])g [ft0 jt0 2 ri0 ^ :(9t)(t 2 ri ^ t[Ki ] = t0 [Ki ])g

6


and let ri ri0 denote the following relation over Ri [Xi ; Ki ], is the (unique) most informative such database that does which computes the information in ri and the noncon ict- not involve random choices. In Fig. 4, SMD1 SMD2 is ing information in ri0 : less informative than SMD1 [ SMD2 because the Mission of Enterprise is missing. Any database strictly more inforft t0 jt 2 ri ^ t0 2 ri0 ^ t[Ki ] = t0 [Ki ]g mative than SMD1 SMD2 but not more informative than SMD1 [ SMD2 has to contain either (Enterprise, 101) or [ftjt 2 ri ^ :(9t0 )(t0 2 ri0 ^ t0 [Ki ] = t[Ki ])g 0 0 0 0 (Enterprise, 102) but not both, which involves a random [ft jt 2 ri ^ :(9t)(t 2 ri ^ t[Ki ] = t [Ki ])g: choice between the two. Given two databases b = fri g1in and b0 = fri0 g1in over IV. Multilevel Relational Model B, let b b0 and b b0 denote, respectively, the databases 0 0 fri ri g1in and fri ri g1in over B. Fig. 4 shows two A multilevel relation scheme is a pair (R[X; K ]; L), where relations SMD1 and SMD2 over the relation scheme SMD R[X; K ] is a relation scheme and L is a lattice. A multilevel of Fig. 2, together with SMD1 SMD2 and SMD1 SMD2 . database schema is a pair (B; L), where B is a schema and L is a lattice. SMD1 Let (B; L) be a multilevel schema, where B = (R; C ), R = fRi [Xi ; Ki ]g1in , and L = (L; ). A multilevel relaStarship Mission Destination tion with tuple-level labeling over multilevel relation scheme Enterprise 101 Rigel (Ri [Xi ; Ki ]; L) is a pair (ri ; i ), where ri is a relation over Ri [Xi ; Ki ] and i is a mapping from tuples over Xi to sets Voyager 102 Talos of levels in L, such that i (t) = fg i t 62 ri , and l 2 i (t) SMD2 if t is labeled at l. A multilevel database with tuple-level labeling over mulStarship Mission Destination tilevel schema (B; L) is a family f(ri ; i )g1in , where Enterprise 102 Rigel (ri ; i ) is a multilevel relation with tuple-level labeling over ( Ri [Xi ; Ki ]; L). We denote it by the pair (b; ), where Discovery 103 Rigel b = fri g1in is a database over B, and = fi g1in SMD1 SMD2 is a family of mappings. Fig. 5 shows a multilevel database over the schema of Fig. 2 and the lattice of Fig. 1. The Starship Mission Destination labels of every tuple are listed to the right of that tuple. 6 Enterprise Rigel Voyager 102 Talos Starship Mission Destination Discovery 103 Rigel 6 Enterprise 101 > SMD1 SMD2 Enterprise 102 Rigel m1 Starship Mission Destination Enterprise 103 Rigel m2 Enterprise 101 Rigel Voyager 102 Rigel m1 Voyager 102 Talos Voyager 102 Talos m2 Discovery 103 Rigel Discovery 103 Rigel ? Fig. 4. Filtering Functions

MissionId 101 101 102 103

Type spy mine explore mine

We can show [21] that b b is a database more inm1 formative than b but less informative then b [ b0 , and is m2 the (unique) most informative such database.4 In Fig. 4, SMD1 SMD2 is more informative than SMD1 because it m1 ; m2 contains the tuple (Discovery, 103, Rigel). It is less infor? mative than SMD1 [ SMD2 because it does not contain the atomic tuple (Enterprise, 102). Fig. 5. A Multilevel Database with Tuple-Level Labeling We can also show [21] that b b0 is a database less informative than b [ b0 . Moreover, any such database that A multilevel relation (ri ; i ) satis es the polyinstantiais strictly more informative than b b0 has to involve a random choice: there is another such database that is in- tion security property if: 4 for every pair of tuples t; t0 2 ri where i (t)\i (t0 ) 6= ;, comparable in information content. In other words, b b0 t[Ki ] = t0 [Ki ] implies t = t0 . 4 By restricting ourselves to key and referential integrity properties, such a database always exists, which is not necessarily the case for In other words, tuples labeled at the same level satisfy all the functional dependencies. A multilevel database (b; ) more general constraints. 0


satis es the polyinstantiation security property if every multilevel relation in (b; ) does. For referential dependency Ri [Y ] ,! Rj , multilevel relations (ri ; i ) and (rj ; j ) satisfy the referential security property if: 5 for every tuple t 2 ri and level l 2 i (t) where t[Y ] 6= 6 , there is a tuple t0 2 rj and a level l0 2 j (t0 ) such that t[Y ] = t0 [Kj ] and l0 l. In other words, the label of every foreign key tuple dominates the label of the primary key tuple it refers to. A multilevel database (b; ) satis es the referential security property if every pair of multilevel relations involved in a referential dependency does. The multilevel database of Fig. 5 satis es polyinstantiation and referential security properties. V. Interpretation Policy

An interpretation policy maps a multilevel schema to a multilevel theory and a multilevel database to a multilevel structure of the multilevel theory. Through this mapping, the super cial syntactic dierence in object labels is abstracted away, and the semantic dierence hidden in object labels is made precise. As a consequence, the interpretation policy makes it possible to compare the semantics of multiple MAC policies. Here, we investigate the interpretation policies for two most common multilevel databases, namely multilevel databases with tuple-level and element-level labeling, where objects are tuples and elements in tuples, respectively. A. Interpretation Policy for Tuple-Level Labeling The interpretation policy for tuple-level labeling is straightforward. Because every tuple in a relation represents an elementary fact, the label of the tuple naturally represents the classi cation of the elementary fact. Recall from Section IV that a multilevel schema is a pair (B; L), where B = (R; C ), R = fRi [Xi ; Ki ]g1in , and L = (L; ). We can construct a multilevel theory (L; fT l gl2L; A) as follows. For every l 2 L, T l is the standard rst-order interpretation of schema B where relation scheme Ri is interpreted as predicate Ril in the vocabulary of T l for 1 i n, and attributes are interpreted as argument positions. Key and referential integrity properties are view constraints and are interpreted as axioms in T l. For example, the key integrity property over the relation scheme MT of Fig. 2 is interpreted as:

MTl (x; y) ^ MTl (x; z ) ! y = z and the referential integrity property over the schema of Fig. 2 is interpreted as: SMDl (x; y; z ) ! (9w)MTl (y; w):

7

relation scheme MT of Fig. 2 and the lattice of Fig. 1 is interpreted as: (8l 2 L)(MTl (x; y) ^ MTl (x; z ) ! y = z ): Similarly, the referential security property over the schema of Fig. 2 and the lattice of Fig. 1 is interpreted as: (8l1 2 L)

SMDl1 (x; y; z ) ! (9l2 2 L)(9w)(l2 l1 ^ MTl2 (y; w))

:

Recall from Section IV that a multilevel database with tuple-level labeling over (B; L) is a pair (b; ), where b = fri g1in and = fi g1in . We can construct a multilevel structure of the multilevel theory (L; fT lgl2L; A), where Ril (t) is true i t 2 ri and l 2 i (t). B. Interpretation Policy for Element-Level Labeling B.1 Multilevel Databases with Element-Level Labeling Let (B; L) be a multilevel schema, where B = (R; C ), R = fRi [Xi ; Ki ]g1in , and L = (L; ). A multilevel relation with element-level labeling over multilevel relation scheme (Ri [Xi ; Ki ]; L) is a pair (ri ; i ), where ri is a relation over Ri [Xi ; Ki ] and i is a mapping from attributes in Xi and tuples over Xi to sets of levels in L, such that i (A; t) = fg i t 62 ri or t[A] = 6 ,5 and l 2 i (A; t) if t[A] is labeled at l. When i (A; t) = i (A0 ; t) for all A; A0 2 Xi , we denote i (A; t) by i (Xi ; t). A multilevel database with element-level labeling over multilevel schema (B; L) is a family f(ri ; i )g1in , where (ri ; i ) is a multilevel relation with element-level labeling over (Ri [Xi ; Ki ]; L). We denote it by the pair (b; ), where b = fri g1in is a database over B, and = fi g1in is a family of mappings. Fig. 6 shows a multilevel database over the schema of Fig. 2 and the lattice of Fig. 1. The labels of every element are listed as a superscript of that element.

Starship Enterprise? Voyager? Voyager? Discovery? MissionId 101m1 102? 103?

Mission 101> 102? 6

103?

Destination Rigel? Rigelm1 Talosm2 Rigel?

Type spym1 explorem1 ;m2 mine?

Fig. 6. A Multilevel Database with Element-Level Labeling

Polyinstantiation and referential security properties are labeling constraints and are interpreted as axioms in A. For 5 Null values are not labeled, which is natural because they do not example, the polyinstantiation security property over the represent elementary facts.

8


B.2 Interpretation Policy As we observed in Section I, the interpretation policy of element-level labeling is problematic. Since elements in tuples of a database do not have direct correspondence to elementary facts, it is unclear what the correspondence is between the label of an element in a tuple and the classi cation of any elementary fact. To formulate a natural interpretation policy for element-level labeling, we use the mapping of element-level labeling to tuple-level labeling developed in [20]. Let (b; ) be a multilevel database with element-level labeling over (B; L). Consider the atomic decomposition Ba of B and the atomic decomposition ba of b. Notice that both b and ba capture exactly the same elementary facts, and every elementary fact captured in b is a conjunction of several elementary facts captured in ba. Hence we de ne the interpretation policy of (b; ) by the interpretation policy of (ba ; )|a multilevel database with tuple-level labeling over (Ba; L). In particular, for every relation ri 2 b, tuple t 2 ri , and attribute A 2 Xi :

8 < i (A; t) = :

Ki (t[Ki ]) if A 2 Ki Yi (t[Ki Y ]) if A 2 Y and t[Y ] 6= 6 Ai (t[Ki A]) if t[A] 6= 6 :

Informally the interpretation policy says that the labels on primary keys classify their existence, and the labels on foreign keys and nonkey attribute elements classify their relationships with primary keys. From this de nition, we derive the key classi cation property of element-level labeling: 6.1 for every tuple t 2 ri and attributes A; A0 2 Ki , i (A; t) = i (A0 ; t), and 6.2 for every tuple t 2 ri , foreign key Y in Ri , and attributes A; A0 2 Y , i (A; t) = i (A0 ; t). In other words, primary and foreign keys are labeled uniformly. From the polyinstantiation security property of tuplelevel labeling, we know that t[Ki ] = t0 [Ki ] and Yi (t) \ Yi (t0 ) 6= ; implies t = t0 for all t; t0 2 riY . Similarly t[Ki ] = t0 [Ki ] and Ai (t) \ Ai (t0 ) 6= ; implies t = t0 for all t; t0 2 riA . Hence we derive the polyinstantiation security property of element-level labeling: 7 for every pair of tuples t; t0 2 ri and attribute A 2 Xi ? Ki where i (A; t) \ i (A; t0 ) 6= ;, t[Ki ] = t0 [Ki ] implies t[A] = t0 [A]. In other words, foreign keys or nonkey attribute elements, which are labeled at the same level and correspond to the same primary keys, are identical. From the referential security property of tuple-level labeling and referential dependency RiY [Ki ] ,! RiK in C a, we know that, for every t 2 riY and l 2 Yi (t), there is t0 2 riK and l0 2 Ki (t0 ) such that t[Ki ] = t0 and l0 l. Similarly, from referential dependency RiA [Ki ] ,! RiK in C a, we know that, for every t 2 riA and l 2 Ai (t), there is t0 2 riK and l0 2 Ki (t0 ) such that t[Ki ] = t0 and l0 l. Hence we derive the primary key security property of element-level labeling:

8 for every tuple t 2 ri , attribute A 2 Xi ? Ki , and level l 2 i (A; t), there is a level l0 2 i (Ki ; t) such that l0 l. In other words, the label of every foreign key or nonkey attribute element dominates the label of the corresponding primary key. Again from the referential security property of tuple-level labeling and referential dependency RiK [Y ] ,! RjK in C a , we know that, for every t 2 riK and l 2 Ki (t), there is t0 2 rjK and l0 2 Kj (t0 ) such that t[Y ] = t0 and l0 l. Similarly, from referential dependency RiY [Y ] ,! RjK in C a , we know that, for every t 2 riY and l 2 Yi (t), there is t0 2 rjK and l0 2 Kj (t0 ) such that t[Y ] = t0 and l0 l. Hence we derive the foreign key security property of element-level labeling for every referential dependency Ri [Y ] ,! Rj in C : 9 for every tuple t 2 ri and level l 2 i (Y; t), there is a tuple t0 2 rj and a level l0 2 j (Kj ; t0 ) such that t[Y ] = t0 [Kj ] and l0 l. In other words, the label of every foreign key dominates the label of the primary key it refers to. All properties derived here have been identi ed in the literature as desirable, indicating that our interpretation policy for multilevel databases with element-level labeling is natural. In particular, our properties 6.1 and 8 together with property 2.1 of Section III-A form the entity integrity as de ned in [10], [12]. Hence our interpretation policy provides a semantic justi cation of entity integrity. With the natural requirement that null values are not labeled, our property 7 is equivalent to the PI-FD property of [23]. Our properties 6.2 and 9 together with property 3.1 of Section III-A provide a formal de nition and semantic justi cation of referential integrity. Fig. 7 shows a multilevel database with tuple-level labeling, over the schema of Fig. 3 and the lattice of Fig. 1. It is semantically equivalent to the multilevel database of Fig. 6, because the two are mapped to the same multilevel theory and structure according to our interpretation policies. The null value in Fig. 6 has disappeared in Fig. 7. VI. View Policy

A view policy is a speci cation of the upward information

ow|believability of low data at high levels, such that, for every level, view constraints at that level are satis ed with believable data at that level. A. Existing View Policies According to the Bell-LaPadula model, low data can be visible at high. However, since low data could contradict high data in terms of the high view constraints, visibility should be distinguished from believability . The lter function [9], [12] and the security logic [5] proposed in the literature take one extreme position by equating believability to visibility, thus maximizing believability. However, integrity is compromised if a low tuple contradicts some high tuples with respect to the high view constraints, which leads to an invalid high database. For example, consider the following multilevel relation over the schema of Fig. 2 and the lattice of Fig. 1:


Starship Enterprise ? Voyager ? Discovery ?

Starship Enterprise Voyager Discovery

MId 101 > 102 ? 103 ?

Starship Destination Enterprise Rigel ? Voyager Rigel m1 Voyager Talos m2 Discovery Rigel ? MissionId 101 m1 102 ? 103 ?

MissionId Type 101 spy m1 102 explore m1 ; m2 103 mine ?

9

semantics of MLR [2] generalize the belief-based semantics, by allowing users to specify, for every tuple at a level, at which higher levels it is believed. When the view policy for a tuple is missing, the default coincides with the belief-based semantics. Believability is minimized modulo user-supplied exceptions, and there is no automatic upward information ow cross levels. This view policy provides maximal exibility, at the price that users are burdened with the tedious task of specifying believability for every tuple and every level. For example, to enable >-subjects to believe whatever information about Enterprise available at ?, the above multilevel relation should be modi ed to: Starship Enterprise

Mission 102

Destination Rigel

?; >

When querying the mission of Enterprise, subjects at ? or > will get back 102, while subjects at m1 or m2 still get back an empty answer. In NTML [29], Thuraisingham rst formalized the distinction between visibility and believability by a proofFig. 7. An Atomic Decomposition of Database theoretic semantics of the multilevel relational model, which consists of a nonmonotonic inference rule stating that low data are believable at high as long as they do Starship Mission Destination not contradict high data. Given two low tuples labeled in6 Enterprise Talos > comparably, what happens if either tuple does not contradict high data, but their combination does? To determine Enterprise 102 Rigel m1 what is believable at high, the result of Thuraisingham's Enterprise 103 Rigel m2 approach would depend on the (random) order in which the nonmonotonic inference rule is applied to these two tuWhen querying the mission of Enterprise, >-subjects will ples, which introduces ambiguity. For example, consider get back both 102 and 103, which contradicts the view the following multilevel relation over the schema of Fig. 2 constraint at > that \starships have unique missions". and the lattice of Fig. 1: Smith and Winslett proposed a belief-based semantics of the multilevel relational model [27], which de nes a mulStarship Mission Destination tilevel relational database as a set of unrelated single-level relational databases, one for every level. They made a clear Enterprise 102 Rigel m1 distinction between visibility and believability, and took Enterprise 103 Talos m2 the other extreme position by allowing no low tuples to be believable at high, thus minimizing believability. Their semantics provides a foundation based on which other seman- When querying the mission of Enterprise, >-subjects will tics could be compared. However a multilevel relational get back either 102 or 103 but not both.6 database that directly employs their semantics would no longer be multilevel|it would be a set of single-level rela- B. Desirable Properties of View Policies tional databases in which there is no upward information From the above discussion on the problems associated

ow cross levels. For example, consider the following mulwith existing view policies, we could identify three desirable tilevel relation over the schema of Fig. 2 and the lattice of properties that a view policy should have: Fig. 1: 1. believable data do not violate view constraints, 2. it maximizes upward information ow, and Starship Mission Destination 3. it is deterministic. Enterprise 102 Rigel ? 6 Notice that such problems occur even with a totally ordered lattice, if we allow arbitrary constraints. For example, a constraint could When querying the mission of Enterprise, >-subjects will state that there should be no more than two starships going to Rigel. If we have one tuple (Enterprise, 101, Rigel) at > together with two get back an empty answer, because no information about tuples (Voyager, 102, Rigel) and (Discovery, 103, Rigel) at ?, then Enterprise is considered believable at that level. at most one tuple at ? is believable at >, but it is unclear which one The maintenance level of LDV [7] and the data-based should be.

10


In the rest of this section, we outline an atomic ow policy for multilevel databases with tuple-level labeling proposed in [21], where the view constraints consist of key and referential integrity properties, which satis es the desirable properties identi ed above. C. View Policy for Tuple-Level Labeling As we observed in Section II-A, a database represents one view of the actual world, while a multilevel database represents multiple views of the actual world|one for every level. Furthermore, these multiple views are constrained by the view constraints and are related by the lattice. Contained in the view at a level are tuples believable at that level. Informally, our view policy states what tuples belong to the view at a level. First, all tuples labeled at that level should be part of the view. Second, for tuples labeled at lower levels, as many of them as possible should be part of the view as long as integrity is preserved, in order to maximize sharing. Third, in case that either but not both of two low tuples could be in a high view, neither of them should be in the high view, because the high view lacks further information to justify the preference of one over the other. In other words, view constraints serve as a lter on how much low data could ow high. Recall from Section IV that a multilevel schema is a pair (B; L), where B = (R; C ), R = fRi [Xi ; Ki ]g1in , and L = (L; ). Let (b; ) = f(ri ; i )g1in be a multilevel database over (B; L), and l 2 L be a level. The l-slice of multilevel relation (ri ; i ), denoted as l (ri ; i ), is a subrelation of ri de ned as ftjt 2 ri ^ l 2 i (t)g. The l-slice of multilevel database (b; ), denoted as l (b; ), is a subdatabase of b de ned as fl (ri ; i )g1in . The l-slices l (ri ; i ) and l (b; ) are, respectively, a singlelevel relation and database collecting all tuples in ri and b that are labeled at l. The >-slice of the multilevel database of Fig. 5 consists of the rst tuple in SMD and no tuples of MT. The l-view of multilevel database (b; ), denoted as &l (b; ) = f&l (ri ; i )g1in where &l (ri ; i ) is the l-view of (ri ; i ), is de ned recursively as follows. If l is the bottom level of L, then &l (b; ) = l (b; ). Otherwise &l (b; ) = bH bL , where bH is l (b; ) and bL is l0 l &l0 (b; ). Notice that the l-views of (ri ; i ) and (b; ) are, respectively, a single-level relation and database. The >-view of the multilevel database of Fig. 5 is shown in Fig. 8. The above de nition formalizes our intuition about views, and satis es the three desirable properties of view policies of Section VI-B, for the following reasons. 1. If the key integrity property is not satis ed in the l-view, then it cannot be satis ed by removing any low tuples from the l-view. If the referential integrity property is not satis ed in the l-view, then it cannot be satis ed by adding any low tuples to the l-view. Thus, believable data do not violate view constraints. 2. All atomic tuples labeled at level l are part of the l-view since bH v &l (b; ) according to the de nition

Starship Enterprise Voyager Discovery

Mission 101 102 103

MissionId 101 102 103

Destination Rigel 6

Rigel Type 6

explore mine

Fig. 8. A >-View

of . For atomic tuples labeled below l, as many of them as possible are part of the l-view since they are part of bH bL according to the de nition of . Thus, upward information ow is maximized. 3. In case that either but not both of two atomic tuples labeled below l could be in the l-view, neither is in the l-view since neither would be in bL according to the de nition of . Thus, upward information ow is deterministic. Our view policy coincides with the Bell-LaPadula model for primary keys, in the sense that all low primary keys are part of the high view. In the extreme case that there are no view constraints (i.e., Xi = Ki for 1 i n and C is empty), our view policy completely coincides with the Bell-LaPadula model, in the sense that S all low tuples are part of the high view, since &l (b; ) = l0 l l0 (b; ). Our view policy is an extension of the Bell-LaPadula model, in the sense that we distinguish between two kinds of low data: those that are believable at high (e.g., the atomic tuple (Enterprise, Rigel)), and those that are visible but not believable at high (because they violate view constraints when combined with high data) (e.g., the atomic tuple (Enterprise, 102)). View constraints are enforced only on believable low data. VII. Update Policy

An update policy consists of a set of updates and a speci cation of the enforcement of labeling constraints on visible data in performing the updates, such that inference channels are eliminated in the enforcement. In particular, if a low update violates labeling constraints when combined with high data, it should not be aborted. Instead it should be extended with necessary compensating high updates in order to enforce integrity, secrecy, and availability. An update policy speci es precisely what the compensating updates should be. A. Existing Update Policies Let us consider the restricted-value policy of [22] and the insert-low policy of [31], both of which are designed to


enforce no-polyinstantiation.7 For easy presentation, we adapt these policies to the context of multilevel databases with tuple-level labeling. Let (B; L) be a multilevel schema, where B = (R; C ), R = fRi [Xi ; Ki ]g1in , and L = (L; ). A multilevel relation (ri ; i ) over (Ri [Xi ; Ki ]; L) satis es the nopolyinstantiation security property if: 10 for every pair of tuples t; t0 2 ri , t[Ki ] = t0 [Ki ] implies t = t0 . In other words, tuples labeled at all levels satisfy all the functional dependencies. A multilevel database (b; ) over (B; L) satis es the no-polyinstantiation security property if every multilevel relation in (b; ) does. If low subjects insert a tuple which has the same primary key as an existing high tuple, then either the low insertion has to be rejected, causing denial of service to low subjects and leading low subjects to infer the existence of the high tuple, or the high tuple has to be overwritten, causing denial of service to high subjects. Similarly, if high subjects insert a tuple which has the same primary key as an existing low tuple, then either the low tuple has to be deleted, causing denial of service to low subjects, or the high insertion has to be rejected, causing denial of service to high subjects. The restricted-value policy and the insert-low policy are very similar. They both remove denial of service to high subjects. The example below illustrates these policies. Consider the following multilevel relation over the schema of Fig. 2 and the lattice of Fig. 1: MissionId 101

Type explore

?

Suppose that a >-subject wants to change explore to spy. The restricted-value policy p extends the update to: 1. Change explore to at ?. 2. Insert (101, spy) at >. The extended update ensures no-polyinstantiation at the price of causing denial of service to ?-subjects. The inference channels at update time are replaced by inference channels at query time, p because ?-subjects can infer from the restricted-value that mission 101 has a high type. In comparison, the insert-low policy extends the update to: 1. Delete (101, explore) at ?. 2. Insert (101, spy) at >. The extended update ensures no-polyinstantiation at the price of causing denial of service to ?-subjects. The inference channels at update time remain, because an insertion of mission 101 by ?-subjects will be rejected, leading ?subjects to infer that mission 101 has a high type.8

11

B. Desirable Properties of Update Policies When a labeling constraint cannot be enforced in performing an update because of an inference channel, the low update could often be extended to a multilevel update that enforces the labeling constraint. We could identify four desirable properties that an update policy should have: 1. it does not introduce new inference channels, 2. it does not aect data at lower or incomparable levels, 3. it does not cause denial of service, and 4. it should minimize the eect on data at higher levels. In [19], we have shown that no update policies exist for the no-polyinstantiation security property that have all these desirable properties, which indicates the inherent dif culty of enforcing unconditional no-polyinstantiation. In the rest of this section, we outline an atomic upgrade policy for multilevel databases with tuple-level labeling proposed in [21], where the labeling constraints consist of polyinstantiation and referential security properties, which satis es the desirable properties identi ed above. C. Update Policy for Tuple-Level Labeling For multilevel databases with tuple-level labeling, a low insertion will not contradict high tuples in terms of the polyinstantiation security property, because uniqueness is not enforced cross levels. On the other hand, a low deletion could violate the referential security property if the deleted low tuple is referred to by high tuples through referential dependencies. To restore referential security, the low deletion could be extended with a high insertion of the atomic tuple containing the primary key of the deleted low tuple. Recall from Section IV that a multilevel schema is a pair (B; L), where B = (R; C ), R = fRi [Xi ; Ki ]g1in , and L = (L; ). Let (b; ) = f(ri ; i )g1in be a multilevel database over (B; L) and l 2 L be a level. The l-fragment of multilevel relation (ri ; i ) , denoted as l (ri ; i ), is a multilevel relation (ri0 ; 0i ) where ri0 is ftjt 2 ri ^(9l0 )(l0 2 i (t)^l0 l)g and 0i (t) is fl0 jl0 2 i (t)^l0 lg for every t 2 ri0 . The l-fragment of multilevel database (b; ), denoted as l (b; ), is a multilevel database de ned as fl (ri ; i )g1in . The l-fragments l (ri ; i ) and l (b; ) collect all tuples and their labels in (ri ; i ) and (b; ) that are labeled at or below l. The m1 -fragment of SMD in Fig. 5 consists of the second, fourth, and sixth tuples. Let t be a tuple over Xi . An update at level l has the form insertlj (t) or deletelj (t), which speci es, respectively, the insertion to or deletion from multilevel relation (rj ; j ) of tuple t at level l. Let oplj (t) be an update at level l where op is either insert or delete. De ne (b0 ; 0 ) = f(ri0 ; 0i )g1in to be a multilevel database over (B; L), where (ri0 ; 0i ) = (ri ; i ) for all i 6= j , and 0j (t0 ) = j (t0 ) for all t0 6= t. De ne rj0 and 0j (t) as follows. 1. op = insert (a) rj0 = rj [ ftg, and

7 No-polyinstantiation can also be enforced by having a more restricted schema, instead of an update policy. For example, the domain of primary key attributes can be partitioned such that primary keys for tuples labeled at dierent levels are disjoint [4]. 8 Both the restricted-value policy and the insert-low policy extend a high update with a low update to eliminate polyinstantiation. In separate transactions. In other words, the trusted user should login order to avoid covert channels, such extension cannot be done auto- at high to perform the high update, and login at low to perform the matically. Rather, it should involve a trusted user performing two low update.

12


(b) 0j (t) = j (t) [ flg. 2. op = delete (a) 0j (t) = j (t) ? flg, and (b) rj0 = rj ? ftg if j (t) = flg. The update oplj (t) applied to multilevel database (b; ) is correct i multilevel database l (b0 ; 0 ) satis es the labeling constraints. If the update is correct, then its result is a multilevel database (~b; ~) = f(~ri ; ~i )g1in de ned as follows. Let t0 be the tuple over Xj where t0 [Kj ] = t[Kj ] and t0 [Xj ? Kj ] = 6 . 1. If op = insert, then (~b; ~) = (b0 ; 0 ). 2. If op = delete, then (~ri ; ~i ) = (ri0 ; 0i ) for all i 6= j , and ~j (t~) = 0j (t~) for all t~ 6= t0 . Let L0 be the set of levels l0 2 L such that l l0 , l0 (b0 ; 0 ) does not satisfy the labeling constraints, and ~l (b0 ; 0 ) satis es the labeling constraints for every ~l 2 L where l l~ l0 . (a) If L0 = fg, then (~b; ~) = (b0 ; 0 ). (b) Otherwise r~j = rj0 [ ft0 g and ~j (t0 ) = 0j (t0 ) [ L0 . For example, deleting the rst two MT tuples consecutively (in either order) from the multilevel database of Fig. 5 would lead to inserting the MT tuple (101, 6 ) at >. Our update policy satis es the four desirable properties of update policies of Section VII-B, for the following reasons. 1. The compensating updates do not introduce new inference channels, because a low update that contradicts high tuples will never be aborted. 2. The compensating updates are at comparably high levels. For any level l0 where l 6 l0, the l0 -slice after an update at l remains the same. The l-slice after an update at l diers from that before the update precisely in the eect of the update. 3. The compensating high updates do not cause denial of service. The low update is never denied, and the compensating high updates involve insertions only. 4. The amount of high data added through compensating high insertions is minimized. First, for any level l0 where l l0 , compensating insertions are performed at l0 only if a deleted tuple at level l is referred to by some tuple at level l0 . Second, the number of levels at which compensating insertions are performed is minimized by the de nition of L0 . Third, the information content of the tuple to be inserted by compensating insertions is minimized by the de nition of t0 .

a consequence, the interpretation policy makes it possible to compare the semantics of multiple MAC policies. As examples, we have developed natural interpretation policies for multilevel relational databases with tuple-level and element-level labeling, respectively, which have properties that are commonly recognized as desirable. The second new component, the view policy, speci es the upward information ow such that, for every level, view constraints at that level are satis ed with believable data at that level. A view policy should have three desirable properties: 1. believable data do not violate view constraints, 2. it maximizes upward information ow, and 3. it is deterministic. As an example, we have developed an atomic ow policy for multilevel relational databases with tuple-level labeling with all these desirable properties, where the view constraints consist of key and referential integrity properties. The third new component, the update policy, speci es the enforcement of labeling constraints on visible data in performing a set of updates, such that inference channels are eliminated in the enforcement. An update policy should have four desirable properties: 1. it does not introduce new inference channels, 2. it does not aect data at lower or incomparable levels, 3. it does not cause denial of service, and 4. it should minimize the eect on data at higher levels. As an example, we have developed an atomic upgrade policy for multilevel relational databases with tuple-level labeling with all these desirable properties, where the labeling constraints consist of polyinstantiation and referential security properties. The components of a MAC policy could interact in complex ways. For example, the view policy of Trusted ONTOS [24] is equivalent to a totally ordered lattice plus NTML [29] as outlined in Section VI-A or the atomic ow policy of Section VI-C. We have also shown in [21] that, for multilevel relational databases with tuple-level labeling, the atomic ow policy of Section VI-C applied to the referential integrity property is equivalent to the belief-based semantics [27] as outlined in Section VI-A applied to the referential security property. The framework provides a basis for systematically specifying MAC policies and characterizing their potential misVIII. Conclusion matches. Based on the framework, we have compared and uni ed the MAC policies and policy components that are A. Summary proposed in the literature or imposed in existing systems. We have developed a formal framework of MAC policies in multilevel relational databases. We have identi ed eight B. Trusted Interoperation components of such policies, and have characterized their desirable properties. Our policy framework could be used to capture and reBesides the ve components in the traditional interpre- solve the MAC policy mismatches in the trusted interopertation of MAC policies in multilevel databases, one of the ation of heterogeneous multilevel databases. As a rst step most important new components is the interpretation pol- in this direction, we have investigated the case when the icy. By mapping multilevel relational databases to multi- MAC policies mismatch in the lattice component [6]. The level theories and structures, the super cial syntactic dif- lattice mismatches are captured in terms of cross-lattice ference in object labels is abstracted away, and the seman- dominance relationships speci ed by, say, a security otic dierence hidden in object labels is made precise. As cer. Secret users of database A would be able to access


sensative data in database B, if level secret in lattice A dominates level sensative in lattice B. To interoperate between multilevel databases with mismatched interpretation policies, some with tuple-level labeling and some with element-level labeling, we utilize the mapping of element-level labeling to tuple-level labeling from Section V-B.2. Databases with element-level labeling would be transformed to virtual databases with tuplelevel labeling through atomic decomposition. Users of a database with tuple-level labeling would be able to access data in a database with element-level labeling through the corresponding virtual database. For example, a >-user of the database in Fig. 5 could query the type of the mission whose MissionId is 101. If this database interoperates with the database in Fig. 6, then he could get back a tuple (101m1 , spym1 ), where the semantics of element-level labels might not be comprehensible to him. If instead, this database interoperates with the database in Fig. 7, then he would get back a tuple (101, spy)m1 , where the semantics of the tuple-level label is understandable to him. Suppose that we want to interoperate between two multilevel databases with mismatched view policies, database A with NTML [29] as outlined in Section VI-A and database B with the atomic ow policy of Section VI-C. Also suppose that database A has an empty SMD relation, and database B is as shown in Fig. 5. If a >-user queries database B directly for the destination of Voyager, he would get back an empty answer. But if he queries database A, then he should get back either Rigel or Talos, from database B through interoperation. Suppose that we want to interoperate between two multilevel databases with mismatched update policies, database A with the restricted-value policy and database B with the insert-low policy, as outlined in Section VII-A. Also suppose that both databases have a ?-tuple (101, Rigel) in relation MT, and updates to MT in one database are automatically propagated to the other. If >-users change Rigel to Talos A, then the ?-update to change Rigel p in database to should not be propagated directly to database B, bep cause would be foreign to users of database B. Instead, it should be replaced by the ?-deletion of (101, Rigel). [1] [2] [3] [4] [5] [6] [7]

References R. K. Burns. Integrity and secrecy: Fundamental con icts in the database environment. In Proceedings of the Third RADC Database Security Workshop, pages 37{40. The MITRE Corporation, 1990. F. Chen and R. S. Sandhu. The semantics and expressive power of the MLR data model. In Proceedings of the 1995 IEEE Symposium on Security and Privacy, pages 128{142, 1995. D. E. Denning. Cryptography and Data Security. AddisonWesley, 1982. C. Garvey and A. Wu. ASD views. In Proceedings of the 1988 IEEE Symposium on Security and Privacy, pages 85{95, 1988. J. Glasgow, G. MacEwen, and P. Panangaden. A logic for reasoning about security. ACM Transactions on Computer Systems, 10(3):226{264, August 1992. L. Gong and X. Qian. Computational issues in secure interoperation. IEEE Transactions on Software Engineering, 22(1), January 1996. J. T. Haigh, R. C. O'Brien, and D. J. Thomsen. The LDV secure relational DBMS model. In S. Jajodia and C. E. Landwehr,

[8] [9] [10] [11] [12] [13]

[14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]

13

editors, Database Security, IV: Status and Prospects, pages 265{ 279. North-Holland, 1991. H. H. Hosmer. Integrating security policies. In Proceedings of the Third RADC Database Security Workshop, pages 169{173. The MITRE Corporation, 1990. S. Jajodia and R. Sandhu. Polyinstantiation integrity in multilevel relations. In Proceedings of the 1990 IEEE Symposium on Research in Security and Privacy, pages 104{115, 1990. S. Jajodia and R. Sandhu. A novel decomposition of multilevel relations into single-level relations. In Proceedings of the 1991 IEEE Symposium on Research in Security and Privacy, pages 300{313, 1991. C. E. Landwehr. Formal models for computer security. ACM Computing Surveys, 13(3):247{278, September 1981. T. F. Lunt, D. E. Denning, R. R. Schell, M. Heckman, and W. R. Shockley. The Seaview security model. IEEE Transactions on Software Engineering, 16(6):593{607, June 1990. T. F. Lunt, P. G. Neumann, D. E. Denning, R. R. Schell, M. Heckman, and W. R. Shockley. Secure distributed data views: Security policy and interpretation for DBMS for a class A1 DBMS. Technical Report RADC-TR-89-313, volume 1, Rome Air Development Center, Air Force Systems Command, December 1989. C. Meadows and S. Jajodia. Integrity versus security in multilevel secure databases. In C. E. Landwehr, editor, Database Security: Status and Prospects, pages 89{101. North-Holland, 1988. J. B. Michael, E. H. Sibley, R. F. Baum, and F. Li. On the axiomatization of security policy: Some tentative observations about logic representation. In B. M. Thuraisingham and C. E. Landwehr, editors, Database Security, VI: Status and Prospects, pages 367{386. North-Holland, 1993. P. Morris and J. McDermid. The structure of permissions: A normative framework for access rights. In C. E. Landwehr and S. Jajodia, editors, Database Security, V: Status and Prospects, pages 77{97. North-Holland, 1992. J.-M. Nicolas and H. Gallaire. Data base: Theory vs. interpretation. In H. Gallaire and J. Minker, editors, Logic and Databases, pages 33{54. Plenum Press, 1978. G. Pernul. Canonical security modeling for federated databases. In Proceedings of the IFIP WG 2.6 Conference on Semantics of Interoperable Database Systems, 1992. X. Qian. Inference channel-free integrity constraints in multilevel relational databases. In Proceedings of the 1994 IEEE Symposium on Research in Security and Privacy, pages 158{167, 1994. X. Qian and T. F. Lunt. Tuple-level vs. element-level classi cation. In B. M. Thuraisingham and C. E. Landwehr, editors, Database Security, VI: Status and Prospects, pages 301{315. North-Holland, 1993. X. Qian and T. F. Lunt. A semantic framework of the multilevel secure relational model. IEEE Transactions on Knowledge and Data Engineering, 1997. R. Sandhu and S. Jajodia. Eliminating polyinstantiation securely. Computers & Security, 11(6):547{562, October 1992. R. Sandhu, S. Jajodia, and T. F. Lunt. A new polyinstantiation integrity constraint for multilevel relations. In Proceedings of the Third IEEE Workshop on Computer Security Foundations, pages 159{165, 1990. M. Schaefer, P. Martel, T. Kanawati, and V. Lyons. Multilevel data model for the trusted ONTOS prototype. In Proceedings of the Ninth IFIP WG 11.3 Working Conference on Database Security, pages 121{141, 1995. E. H. Sibley, J. B. Michael, and R. L. Wexelblat. Use of an experimental policy workbench: Description and preliminary results. In C. E. Landwehr and S. Jajodia, editors, Database Security, V: Status and Prospects, pages 47{76. North-Holland, 1992. G. Smith. Modeling security-relevant data semantics. IEEE Transactions on Software Engineering, 17(11):1195{1203, November 1991. K. Smith and M. Winslett. Entity modeling in the MLS relational model. In Proceedings of the Eighteenth International Conference on Very Large Data Bases, pages 199{210, 1992. G. Steinke and M. Jarke. Support for security modeling in information systems design. In B. M. Thuraisingham and C. E. Landwehr, editors, Database Security, VI: Status and Prospects, pages 125{141. North-Holland, 1993. B. M. Thuraisingham. A nonmonotonic typed multilevel logic for multilevel secure database/knowledge-base management sys-

14


tems. In Proceedings of the Fourth IEEE Workshop on Computer Security Foundations, pages 127{138, 1991. [30] J. D. Ullman. Principles of Database and Knowledge Base Systems, volume 1. Computer Science Press, 1988. [31] S. R. Wiseman. Control of con dentiality in databases. Computers & Security, 9(6):529{537, October 1990.

Xiaolei Qian received the B.Sc. degree from

Xian Jiao Tong University, Xian, China, in 1982, and the M.Sc. and Ph.D. degrees from Stanford University, Stanford, CA, in 1984 and 1989, respectively, all in computer science. She is a Senior Computer Scientist in the Computer Science Laboratory at SRI International. Her research interests include database security, semantic interoperation and integration of heterogeneous databases, and software architectures. She is also interested in constraint management, database programming languages, and formal methods.

Teresa F. Lunt is program manager for infor-

mation security in ARPA/ITO. Prior to joining ARPA, she was Program Director for Secure Systems Research at SRI International, where she directed a program in computer security that performed basic research and technology development for database security, intrusion detection, inference control, and secure database interoperation. She has published numerous papers and reports and edited a book on database security. She was an organizer of the IEEE Symposium on Security and Privacy for several years, and has organized numerous workshops on database security and intrusion detection. She received the A.B. from Princeton University in 1976 and an M.A. from Indiana University in 1979.