segment, and the #write privilege, which allows a subject to modify all the objects in a segment. GemStone also supports the special privilege #none, which, when granted to a subject, deletes authorizations. 11.4 Multilevel Security in Database Systems This section describes the multilevel security aspects of mandatory security for DB systems. The first part focuses mainly on relational systems. Then we provide an overview of secure object systems. Note that several other signifi- cant developments have been made in multilevel security for DB systems, including inference problems, secure concurrency control, and recovery algo- rithms, and multilevel security for distributed, heterogeneous, and federated DB systems. This chapter does not discuss all those developments. For details on inference problems, we refer the reader to [25]; for secure concurrency control, [26]; for secure distributed, heterogeneous, and federated DBs, [27]. 11.4.1 Multilevel Relational Data Model In a multilevel DB, not all the data are assigned the same security level. If such a DB is based on the relational model, the objects of classification may be the entire DB, relations, tuples, attributes, or data elements. Access to those objects is governed by the mandatory policy discussed in Section 11.2. A multilevel DBMS should protect the multilevel DB from unauthorized access or modification by subjects cleared at different security levels. A multi- level relational DB represents the multilevel DB as a set of relations. The cor- responding model is called a multilevel relational data model. A goal of a multilevel relational DB designer is to represent multiple versions of the same entity, action, or event at different security levels with- out violating the integrity or security rules. One of the mechanisms being proposed to represent multiple versions of an entity at different security levels is polyinstantiation. Polyinstantiation enables two tuples with the same primary key to exist in a relational DB at different security levels. However, having two tuples with the same primary key violates the entity-integrity property of the standard relational data model. If polyinstantiation is not supported, then it is possible for signaling channels to occur. Consider the following example. EMP is a relation with attributes SS#, NAME, SALARY, and DEPT#. Let SS# be its primary key. Suppose a subject enters the tuple (000, John, 60K, 120) first into EMP. Later suppose an Unclassified subject enters the tuple (000, John, 20K, 120) into EMP. If the tuple is accepted, Secure Database Systems 375 then it is a polyinstantiated tuple. If the tuple is rejected due to entity- integrity violation, then the actions of a Secret subject have interfered with those of an Unclassified one. Recently there has been much discussion on polyinstantiation. Some argue that polyinstantiation is necessary if we are to design multilevel DB sys- tems with higher levels of assurance (see, e.g., [11]). Some argue that it is important to maintain the integrity of the DB and that polyinstantiation vio- lates the integrity (see, e.g., [28]). Some have used partial polyinstantiation together with security constraint enforcement in their design (see, e.g., [29]). An interesting operational example that shows the disastrous effects of poly- instantiation is given in the paper by Wiseman [30]. Even among those who support polyinstantiation, there has been much discussion of the correct update semantics to use. A logic for formalizing concepts in multilevel rela- tions that supports polyinstantiation is given in [31]. Various systems dis- cussed here have proposed various types of multilevel data models. They all satisfy the security properties discussed in Section 11.2. The entities of classi- fication are mostly the tuples. Polyinstantiation is supported in most of the models. 11.4.2 Architectures This section describes various access control models that have been devel- oped for MLS/DBMSs. While DBMSs must deal with many of the same security concerns as trusted operating systems (identification and authenti- cation, access control, auditing), there are characteristics of DBMSs that introduce security difficulties over and above those that could be handled by traditional operating system security techniques. For example, objects in DBMSs tend to be of multiple sizes and can be of very fine granularity. That contrasts with operating systems in which the granularity tends to be coarse and uniform (e.g., files or segments). Because of the variety of granularity in TDBMSs, the objects on which MAC and DAC may be performed may dif- fer. In trusted operating systems, MAC and DAC tend to be performed on the same objects. There are also some obvious functional differences between operating systems and DBMSs, which affect how the two deal with security. Operating systems tend to deal with subjects attempting to access some objects. DBMSs are used to share data between users and to provide users with a means to relate different data objects. Also, DBMSs generally are dependent on oper- ating systems to provide resources and isolation for the DBMS. Therefore, 376 Advanced Database Technology and Design TDBMS designs often must take into account how the operating system deals with security. The differences between DBMSs and operating system functional and security requirements mean that the traditional approaches to developing secure systems that worked so well for operating systems need to be modified for TDBMSs. Currently, no single architectural approach has been agreed on or employed in the development of MLS/DBMSs. A variety of approaches to designing and building MLS/DBMSs have been proposed. Taxonomies for MAC have been proposed (see, e.g., [32, 33]). This chapter merges the vari- ous ideas proposed as well as uses the notes from tutorials the authors have given (see, e.g., [34]). 11.4.2.1 Single-Kernel Architecture The single-kernel approach, also known as the Hinke-Schaefer approach, is characterized by having the underlying trusted operating system perform all the access control mediation. No access control mediation is performed by the DBMS. The DBMS objects (e.g., records) are aligned with the underly- ing operating system objects (e.g., files). Thus, Secret records are stored in Secret files, TopSecret records are stored in TopSecret files, and so on. Under this approach, no single DBMS has access to all the data in the DB; rather, there is an instantiation of the DBMS for each security level. The advantages of this approach are its simplicity and high degree of security. The disadvan- tage is that performance is likely to degrade significantly as the number of security levels increases (see, e.g., the work of Graubart in [32]). 11.4.2.2 Distributed Architecture Under the distributed approach, there are multiple untrusted (in terms of MAC) back-end DBMS machines, and a single trusted front-end machine to which all the untrusted back ends communicate. There are two primary versions of this architecture. One version has only a single level of data per machine. Thus, one machine would have only Secret data, another would have TopSecret data, and so on. We refer to this version as the partitioned approach. Under the second version, lower level data are replicated on the various machines. Thus, the Secret machine will have the Secret data, the Confidential data, and the Unclassified data; the Confidential machine will have the Confidential data and the Unclassified data; and so forth. We refer to this second version as the replicated approach. Under the partitioned approach, the trusted front end is responsible for ensuring that queries are directed to the correct machines and for performing joins on the data passed back by the various machines. Because the query Secure Database Systems 377 itself could contain information classified higher than some of the target machines (and because the trusted front end would be unable to ascertain if that is the case), this partitioned approach suffers from a potentially high sig- naling channel, as queries are sent to machines that are operating at levels lower than the user. For the replicated approach, the trusted front end ensures that the query is directed to a single machine. Because only machines operating at the same level as the user are queried, replicated approach does not suffer from the signaling channel problem. Nor does the replicated approach require that the front end perform any of the join operations. However, because the data are replicated, the trusted front end must ensure consistency of the data maintained in the various machines. The advantage of the distributed approaches is that they provide high- assurance separation between the data, and performance is likely to be inde- pendent of the number of security levels. The disadvantage is the high cost in hardware (one machine per security level) and the physical space require- ments for the placement of the machines. 11.4.2.3 Trusted-Subject Architecture The trusted-subject approach, also sometimes called a dual kernelbased architecture [32], does not rely on the underlying operating system to per- form access control mediation. Under this approach, the DBMS performs its own access mediation for objects under its control. Thus, access to DBMS records is mediated by the TDBMS. The architecture is referred to as a trusted-subject approach because the access mediation provided by the TDBMS is not independent from the access mediation of the operating sys- tem and must act as a trusted subject to ensure that no violation of the overall security policy occurs. Under the trusted-subject approach, a single DBMS has access to all the data in the DB. The advantages of this architecture are that it can provide good security and that its performance is independent from the number of security levels involved. Its disadvantage is that the DBMS code that performs access mediation must be trusted, and often such code is both large and complex. Another disadvantage with this approach is that the evaluation of such architectures may require reevaluation of part or all of the underlying trusted operating systems on which the DBMS is built. 11.4.2.4 Integrity Lock Architecture The integrity-lock approach employs an untrusted DBMS back end with access to all the data in the DB; an untrusted front end, which communicates with the user; and a trusted front end, which makes use of encryption 378 Advanced Database Technology and Design technology (see, e.g., [35]). It is essential that the untrusted components are isolated from each other so there is no communication between the two without the intervention of the trusted filter. This isolation can be provided either by physical isolation (the front and back ends can be on two different machines) or by logical isolation via the MAC mechanism of the underlying operating system. Assuming the latter approach is employed, the back end should be maintained at system high. Multiple instantiations of the front end would be maintained, with one instantiation for each user level. The trusted filter exists at the same level as the back end. Under this approach, every tuple that is inserted into the DB has asso- ciated with it a sensitivity label and a cryptographic checksum, employing a CBC algorithm (both supplied by the trusted front end). The sensitivity label should also be encrypted, but the data tuple itself remains unencrypted. For insertions, the untrusted DBMS back end takes the data tuple and asso- ciated label and checksum and places them in the DB, as it would with any other data tuple. On retrieval, the back end retrieves the data tuples and passes them to the trusted front end, which validates the label and the check- sum. If the label and the checksum satisfy the validation check, the tuple is passed to the user or any waiting untrusted processes. The advantage of this approach is that a minimal amount of additional trusted code is required for the TDBMS, and performance is independent of the number of security levels involved. The disadvantage is that this approach is subject to an inference threat, which occurs because the untrusted back end is able to view classified data, encode it as a series of unclassified data tuples, and pass the encoded data tuples to the trusted front end. Because the data tuples would all be unclassified, the trusted filter will allow the tuples to be passed on to a subject not cleared for classified data. 11.4.2.5 Extended-Kernel Architecture The extended-kernel approach is an extension of the single-kernel approach. The underlying operating system is still employed to provide the basic MAC and DAC mediation. However, the TDBMS will supplement this access mediation by providing some additional access control mediation. Thus, if the operating system provides standard content-independent DAC on files, the TDBMS might provide context-dependent DAC on views. This approach differs from the trusted-subject approach because the policies enforced by the TDBMS are not dependent on those of the operating system and can only further restrict the access restrictions imposed by the operating system. This approach suffers from the same performance difficulties of the single-kernel approach. Also, it is likely to be somewhat complex. However, Secure Database Systems 379 because it provides more sophisticated access control mechanisms, it is likely to be capable of addressing some additional real-world access control needs. 11.4.3 Prototypes This section examines two prominent research prototypes that were designed in the late 1980s: SRIs SeaView and Honeywells LOCK Data Views (LDV). Both are based on the extended-kernel approach. Many of the MLS/DBMS products discussed in this chapter have been heavily influenced by those two systems. Other MLS/DBMSs designed in the 1980s and the early 1990s include ASD-Views by TRW, integrity-lock prototypes by MITRE, Secure Distributed Database Systems by Unisys, SINTRA by Naval Research Laboratory, and SWORD by Defense Research Agency. Note that in describing SeaView and LDV, we discuss the design of the initial systems. Table 11.2 classifies the various prototypes and products according to the design on which they are based. A discussion of some of these prototypes and products is given in the following sections. Since most multilevel object models also include policies for method execution, we have not considered them in this classification. There is no taxonomy yet for multilevel object systems. 11.4.3.1 SeaView SeaView, which is an MLS relational DDBMS hosted on GEMSOS Trusted Computing Base (TCB), addresses the multilevel secure needs by enabling individuals possessing a range of clearances to create, share, and manipulate relational DBs that contain information spanning multiple sensitivity levels. Its designers goal was to develop a high-assurance MLS/DBMS. The project 380 Advanced Database Technology and Design Table 11.2 Classification of Products and Prototypes Based on Their Architecture Architecture Prototypes and Products Single kernel Hinke-Schaefer, SeaView, Oracle (based on Hinke-Schaefer) Distributed Unisyss Secure Distributed Database, Naval Research Laboratorys SINTRA Trusted subject TRWs ASD-Views, Secure Sybase, Trusted Oracle (based on trusted subject), Trusted Informix Integrity lock MITRE prototypes, TRUDATA Extended kernel Honeywells LDV addressed some difficult issues such as polyinstantiation, inference, and aggregation. In addition, algorithms for decomposing multilevel relations into single-level relations as well as recombining the single-level relations to form a multilevel relation were developed. The relational query language SQL was extended to MSQL to include multilevel security constructs. Since the project began in 1985, it has attained much prominence, and SeaView is now being regarded by many as one of the key MLS/DBMS prototypes to be developed. We first provide an overview of SeaView and then discuss its security model, which is unique. This discussion of SeaView is obtained from [5]. To obtain high assurance, SeaView design is based on the reference monitor concept. Subjects have the view of multilevel relations, which are relations with data at different security levels. A subject at level L could have a view of a multilevel relation with data classified at or below level L. A mul- tilevel relation is stored in one or more single-level relations. The single-level relations are transparent to the subject. A single-level relation is stored in a file (or segment) at the same level, and the reference monitor controls access to the single-level files. Implementing multilevel relations as virtual relations (or views) enables subjects to issue insert, delete, and update requests on those views. Appropriate algorithms are then used to translate the update on views to an update on the base relations, which are single level. An advan- tage of the SeaView approach is that the labels of the data elements need not be stored. That is because the level of the file in which a data element is stored is the level of the data element. However, if many security levels are to be supported, there will be considerable performance impact on query processing. That is because several files will have to be accessed to form a view of a multilevel relation. Each DB operation is carried out by a single-level subject. When a sub- ject at level L issues a request, a DB system subject operating at level L will process the subjects request. The designers believe that having single-level subjects carry out the DB operations will considerably reduce disclosure risks. However, with this approach there must be a DB server operating at each security level supported by the system, that is, multiple DB servers share the same logical DB. The SeaView security model consists of two components: the MAC model and the TCB model. The MAC model defines the mandatory security policy. The basic constructs are subjects, objects, and access classes. Each subject is assigned a readclass and a writeclass. A subject can read an object if the subjects readclass dominates the access class of the object. A subject can write into an object if the objects access class dominates the writeclass of the Secure Database Systems 381 subject. The TCB model defines discretionary security and supporting poli- cies for multilevel relations, views, and integrity constraints, among others. The data model utilized by SeaView is a multilevel relational data model. It supports element-level classification. Polyinstantiation is the mechanism introduced by SeaView to handle cover stories as well as signaling channels. For example, in a multilevel world, it is possible to have multiple views of the same entity at different security levels. In the SeaView model, the two views may be represented by, say, two tuples with the same primary key but at dif- ferent security levels. The primary key constraint is not violated because, in the multilevel relational data model proposed by SeaView, a modified entity integrity property is defined. Additional integrity properties such as referen- tial integrity and polyinstantiation integrity are also defined in the SeaView model. 11.4.3.2 LOCK Data Views The LOCK Data Views (LDV) system, which is an MLS relational DBMS hosted on LOCK TCB, addresses the multilevel secure needs by enabling individuals possessing a range of clearances to create, share, and manipulate relational DBs that contain information spanning multiple sensitivity levels. In LDV, the relational query language SQL is enhanced with constructs for formulating security assertions. Those security assertions serve to imply sensitivity labels for all atomic values, contexts, and aggregations in a DB. The labeled data are partitioned across security levels, assigned to containers with dominating security markings or levels, and may only flow upward in level unless authorized otherwise. The ability of LDV to perform in this manner is a function of its design and the operating system on which it is hosted. The design of LDV is unique because it is based on LOCKs type- enforcement mechanism. A detailed discussion of LDV is described in [25]. To understand the LDV security policy, it is essential to understand the LOCK security policy, which consists of a discretionary and a mandatory security policy. The discretionary policy allows subjects to specify and con- trol the sharing of objects. The mandatory policy is based on controlling the potential interferences among subjects. It consists of a MAC policy and a type-enforcement policy. The MAC policy is based on the Bell and LaPadula policy. The type-enforcement policy deals with aspects of security policy that are inherently nonhierarchical in nature. It restricts accesses of subjects to objects based on the domain of the subject and the type of the object. The additional concern for a DBMS in a multilevel secure environ- ment beyond that of LOCK is the proper labeling of information. To pro- vide for that concern, two extensions to the policy of the TCB are required. 382 Advanced Database Technology and Design One extension summarizes the actions that happen when a DB is updated and the other when a query is made to the DB. The update classification pol- icy addresses the problem of proper classification of the DB data. That is, when the DB is updated, the classification level of the data is determined. The data are then inserted into an object whose level dominates the level of the data. The response classification policy addresses the problem of proper clas- sification of response to queries. This is a problem because the response may be built based on the data in many base relations. In the process of manipu- lating and combining the data, it is entirely possible that the data will be used in a manner that reveals higher level information. The problem becomes more acute when one realizes that the response will be released into an environment in which many responses may be visible. Thus, the problem becomes one of aggregation and inference over time as well as across rela- tions. In light of that, it seems fairly clear that a response can be released only if it is placed in an object whose level dominates the derived level of the response. The derived level is the maximum level of any information that can be deduced from the response by a subject reading the response. LOCKs type-enforcement mechanism allows us to encapsulate applications such as DBMS in a protected subsystem, by declaring the DBMS objects to be of special types that are accessible only to subjects executing in the DBMS domain. The subjects who are allowed to execute in this domain are carefully restricted. It is this approach that makes LDV a unique design. Some of the essential design concepts of LDV are the following. • Subjects interact with LDV through a request importer and a request exporter. • Access to data as well as to metadata is controlled by LOCK. • Information in the DB as well as the meta-DB is stored in single- level files, that is, LOCK objects. LOCK ensures that the DB files may be opened for read/write operations only by subjects executing at the appropriate levels and in the appropriate DB domains. • The LDV subsystems are the Data Dictionary Manager (DDM), which is responsible for maintaining all information about the mul- tilevel DB; the User Request Manager (URM), which provides interface subjects; the Relational Access Manager (RAM), which is responsible for query optimization; and the Execution Manager (EM), which is responsible for file and transaction management. Secure Database Systems 383 TEAMFLY Team-Fly ® 11.4.4 Commercial Products Since 1988, MLS/DBMS products have been developed. However, some of those products are not being marketed anymore. Furthermore, some corpo- rations have merged with other corporations, so the ownership of the prod- ucts also has changed. This section is an overview of the commercial products that emerged between 1988 and 1993. Note that in describing the product we do not mention the evaluation status. Our emphasis is on the technical aspects of the product for the initial release. We also briefly mention the plat- forms they were intended to run on initially. Because the MLS/DBMS com- mercial marketplace has been dominated by relational systems, we discuss only relational DBs. 11.4.4.1 TRUDATA The initial version of the TRUDATA system designed in the late 1980s is an approach based on Integrity-Lock whose underlying security model is derived from the Naval Surveillance Model as well as from Integrity-Lock architecture. TRUDATA employs an untrusted Britton Lee DB machine as a back end and an AT&T 3B2 V/MLS system as a front end. The back-end DB machine is completely untrusted and has access to all the data in the DB. The back-end machine performs standard DBMS selection, joins, and projections, as well as being responsible for data storage and recovery. In TRUDATA physical, not logical, isolation is used to isolate the DB from non-DBMS code. Trusted code added to the MLS front end associates labels and a 64-bit CBC checksum to the data being stored in the DB. The trusted filter also performs all access mediation (MAC and DAC). Objects in TRUDATA are view instances (pviews, mviews, and rela- tions). Pviews are projections from a given relation. The pviews are defined a priori before data are inserted into the DB. Mviews are the join between two or more pviews. The intent of labeling only view instances is to limit the inference threat to which systems based on Integrity-Lock are vulnerable. TRUDATA provides two versions of its MAC policy: a restricted version, which allows only a write-equal policy, and an unrestricted version, which allows a write-up policy. Objects in TRUDATA may be labeled with one of three types of labels: an actual security label (ASL), a default security label (DSL), or a container clearance requirement (CCR) label. An ASL may be associated with only a pview instance. A DSL is attached to every container. Pview instances, which do not have an ASL associated with them, inherit the DSL of their container. The inheritance mechanism allows subjects to avoid having to label all view 384 Advanced Database Technology and Design [...]... Extending Database Technology (EDBT 88 ), Venice, Italy, 1 988 400 Advanced Database Technology and Design [10] Bertino, E., P Samarati, and S Jajodia, “An Extended Authorization Model,” IEEE Trans on Knowledge and Data Engineering, Vol 9, No 1, Jan./Feb 1997, pp 85 –101 [11] Denning, D E., and T Lunt, “A Multilevel Relational Data Model,” Proc IEEE Symp on Security and Privacy, Oakland, CA, Apr 1 987 [12]... Griffiths, P P., and B W Wade, “An Authorization Mechanism for a Relational Database System,” ACM Trans on Database Systems, Vol 1, No 3, Sept 1976, pp 242–255 [8] Wilms, P F., and B G Linsday, “A Database Authorization Mechanism Supporting Individual and Group Authorization,” Distributed Data Sharing Systems, 1 982 , pp 273–292 [9] Bertino, E., and L M Haas, “Views and Security in Distributed Database Management... Proc VLDB Conf., 1991 Secure Database Systems 401 [25] Morgenstern, M., “Security and Inference in Multilevel Database and Knowledge Base Systems,” Proc ACM SIGMOD Conf., San Francisco, CA, 1 987 [26] Bertino, E., B Catania, and A Vinai, “Transaction Modelling and Architectures,” Encyclopedia of Computer Science and Technology, Vol 38, No 23, New York: Marcel Dekker, 19 98, pp 361–400 [27] Thuraisingham,... Secure Database Systems,” MITRE Technical Report, June 1992 [35] Graubart, R D., “The Integrity Lock Approach to Secure Database Management,” Proc IEEE Symp on Security and Privacy, Oakland, CA, Apr 1 984 [36] Keefe, T., T W Tsai, and B Thuraisingham, “SODA—A Secure Object-Oriented Database System,” Computers & Security, Vol 8, No 6, 1 989 [37] Thuraisingham, B., “Mandatory Security in Object-Oriented Database. .. Conf in Database Security, Halifax, England, 1990 [41] Rosenthal, A., et al., “Security for Object-Oriented Systems,” Proc IFIP 11.3 Working Conf on Database Security (Hildesheim), 1994 402 Advanced Database Technology and Design [42] Bertino, E., “Data Security,” Data & Knowledge Engineering, Vol 25, No 1–2, Mar 19 98, pp 199–216 [43] Bertino, E., E Ferrari, and V Atluri, “The Specification and Enforcement... supports in that respect Recently, however, more and more new and demanding application domains have emerged that also want to benefit from DB technology, and 403 Team-Fly® 404 Advanced Database Technology and Design new requirements have been posed to DBMSs (see Chapter 1) First, many applications require the management of data types that are not handled well by conventional DBMSs Examples of such... 1 485 , 19 98 [20] Ahad, R., et al., “Supporting Access Control in an Object-Oriented Database Language,” Proc Intl Conf on Extending Database Technology (EDBT), Vienna, Austria, Springer-Verlag, LNCS 580 , 1992 [21] Bruggemann, H H., “Rights in Object-Oriented Environments,” Proc 7th Working Conf on Database Security, 1992, pp 99–115 [22] Fernandez, E., E B Gudes, and H Song, “A Model for Evaluation and. .. Next-Generation Database Systems,” ACM Trans on Database Systems, Vol 16, No 1, Mar 1991, pp 88 –131 [ 18] Bertino, E., and H Weigand, “An Approach to Authorization Modelling in ObjectOriented Database Systems,” Data & Knowledge Engineering, Vol 12, No 1, 1994 [19] Bertino, E., et al., “A Flexible Authorization Model and Its Formal Semantics,” Proc 5th European Symp on Research in Computer Security (ESORICS’ 98) ,... Heterogeneous and Federated Databases,” Computers & Security, Vol 14, Dec 1994 [ 28] Burns, R., “Referential Secrecy,” Proc IEEE Symp on Security and Privacy, Oakland, CA, May 1990 [29] Stachour, P., and M B Thuraisingham, Design of LDV—A Multilevel Secure Database Management System,” IEEE Trans on Knowledge and Data Engineering, Vol 2, No 2, 1990 [30] Wiseman, S., “On the Problem of Security in Databases,”... E., S Jajodia, and P Samarati, “Supporting Multiple Access Control Policies in Database Systems,” Proc IEEE Symp on Security and Privacy, Oakland, CA, 1996 [13] Sandhu, R., et al., “Role-Based Access Control Models,” IEEE Computer, Feb 1996, pp 38 47 [14] Bertino, E., et al., “Reasoning With Temporal Authorizations and Periodicity Constraints in Database Access Control,” ACM Trans on Database Systems, . untrusted front end, which communicates with the user; and a trusted front end, which makes use of encryption 3 78 Advanced Database Technology and Design technology (see, e.g., [35]). It is essential. that of the object. 388 Advanced Database Technology and Design 3. A subject can execute a method if the subjects security level domi- nates the security level of the method and that of the class. to the policy of the TCB are required. 382 Advanced Database Technology and Design One extension summarizes the actions that happen when a DB is updated and the other when a query is made to the