Secure Database Design Principles
This chapter describes design principles for Multilevel Secure Database Management Systems (MLS/DBMS). These are the principles based upon which the various MLS/DBMSs have been designed. In particular, we provide a taxonomy for the various designs for a MLS/DBMS. Note that these DBMSs may be based on relational models or they may be based on object models, logic-based models, or any of the other models discussed in Chapter 7.
Before we discuss the taxonomy, we provide some information on mandatory access control for DBMS. This type of access control is the one that is utilized by MLS/DBMS. We discuss the Bell and LaPadula security policy and its interpretation for MLS/DBMS. Then we describe the taxonomy for MLS/DBMS. Note that the taxonomy essentially gives us various security architectures to design MLS/DBMS.
The organization of this chapter is as follows. Mandatory access control including a discussion of security policies is provided in 2. Various security architectures are discussed in Section 3. The chapter is summarized in Section 4.
2 Mandatory Access Control
This section describes mandatory access-control models that have been developed for DBMS. Although DBMS must deal with many of the same security concerns as trusted operating systems (identification and authentication, access control, auditing), there are characteristics of DBMSs that introduce additional security challenges. For example, objects in DBMSs tend to be of varying sizes and can be of fine granularity such as relations, attributes, and elements. This contrasts with operating systems where the granularity tends to be coarse such as files or segments. Because of the fine granularity in MLS/DBMS, also often called Trusted Database Systems (TDBMS), the objects on which MAC (Mandatory Access Control) and DAC (Discretionary Access Control) are performed may differ. In MLS operating systems, also called Trusted Operating Systems, MAC and DAC are usually performed on the same object such as a file.
There are also some functional differences between operating systems and DBMS. Operating systems tend to deal with subjects attempting to access some object. DBMSs are employed for sharing data between users and to provide users with a means to relate different data objects. Also, DBMSs are generally dependent upon operating systems to provide resources such as interprocess communication and memory management. Therefore, trusted DBMS designs often must take into account how the operating systems deal with security.
The differences between DBMS and operating systems discussed above mean that the traditional approaches utilized to developing secure systems need to be adapted for trusted DBMS. Currently there is no standard architectural approach in the development of MLS/DBMS. A variety of approaches to designing and building MLS/DBMS has been proposed. Taxonomies for mandatory access control have been proposed by Hinke and Graubart among others.
In this chapter we describe various approaches for designing a MLS/DBMS. This is also referred to as a taxonomy for MLS/DBMSs. Essentially, MLS/DBMS have been designed based on one of the several architectures discussed in Section 3. Figure 1 illustrates the essential differences between access control in operating systems and access control in DBMSs.
Figure 1 Access control in operating systems and database systems.
2.2 Mandatory Access-Control Policies
Mandatory access-control policies specify access that subjects have to objects. Many of the commercial DBMS are based on the Bell-LaPadula policy specified for operating systems. Therefore, we first state this policy and then discuss how this policy has been adapted for DBMS. Note that other mandatory policies include the non-interference policy by Goguen and Messeguer. However, these policies are yet to be investigated fully for DBMS, although the LOCK Data Views project did some preliminary investigation.
In the Bell-LaPadula policy, subjects are assigned clearance levels and they can operate a level up to and including their clearance levels. Objects are assigned sensitivity levels. The clearance levels as well as the sensitivity levels are called security levels. The set of security levels forms a partially ordered lattice with Unclassified < Confidential < Secret < TopSecret. The following are the two rules of the policy.
- Simple Security Property: A subject has read access to an object if its security level dominates the level of the object.
- *-Property (read "star" property): A subject has write access to an object if the subject's security level is dominated by that of an object.
These properties apply to database systems also. However, for database systems, the *-property is usually modified to read as follows. A subject has write access to an object if the subject's level is that of the object. This means a subject can modify relations at its level.
An important aspect now considered to be part of the security policy for database systems is polyinstantiation. That is, the same object can have different interpretation and values at different levels. For example, at the Unclassified level an employee's salary may be 30,000 and at the Secret level the salary may be 70,000. With multilevel relational models one can have both entries but with their security levels as an additional attribute. One of the main motivations toward handling polyinstantiation is to avoid what are called covert channels. For example, if there is an entry at the Secret level that John's salary is 70K and if an Unclassified subject wants to enter that John's salary is 30K, and if the update is not permitted, there could be a signaling channel from a higher level to a lower level. Over time this could become a covert channel. Many discussions and debates have taken place on polyinstantiation in the early 1990s; for example, the panel at the Computer Security Foundations Workshop in Franconia, NH in 1991. No consensus has been reached. Various systems have implemented multilevel relational data models in different ways. Figure 2 illustrates a mandatory policy for DBMS.
Figure 2 Mandatory policy for DBMS.
3 Security Architectures
Various security architectures have been proposed for secure database systems. Security architectures are essentially system architectures that have been designed with security in mind. This section examines five architectures for MLS/DBMS. As stated in Section 1, these architectures provide a taxonomy for MLS/DBMS.
Figure 3 illustrates the various security architectures. These architectures are: integrity lock architecture, operating system enforcing mandatory security architecture, kernel extensions architecture, trusted subject architecture, and the distributed architecture. Note that the distributed architecture is divided further based on the partitioned approach and the replication approach. Sections 3.2 to 3.6 describe the five architectures.
Figure 3 Security architectures and taxonomy.
3.2 Integrity Lock
This approach utilizes an untrusted back-end DBMS with access to the data in the database, an untrusted front end that communicates with the user, and a trusted front end that makes use of encryption technology (see Figure 4). The untrusted components are isolated from each other so that there is no communication between the two without the mediation of the trusted filter (also called the trusted front end). The back-end DBMS is maintained at system-high. Note that system-high is the highest level supported by the system and system-low is the lowest level. Multiple instantiations of the front end are maintained. There is one instantiation for each user level. The trusted filter is also maintained at system-high.
Under this approach every tuple that is inserted into the database has associated with it a security label (also called a sensitivity label) and a cryptographic checksum. The security label is encrypted and the data is unencrypted. The checksums are computed by the trusted filter on insertion and recomputed during retrieval. For insertions, the trusted filter computes the checksum and the untrusted back-end DBMS takes the data (i.e., the tuple) and associated label and checksum and stores them in the database. On retrieval, the back end retrieves the data tuples and passes them to the trusted filter which recomputes the checksum based on the tuple and label retrieved. If the trusted filter determines that the data has not been tampered with, it passes the data to the user via the untrusted front end.
Figure 4 Integrity lock architectures.
The advantage of this approach is that a small amount of additional trusted code is required for the MLS/DBMS, and performance is independent of the number of security levels involved. The disadvantage is that this approach is subject to an inference threat. This threat 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 are unclassified, the trusted filter will not be able to detect the covert operations of the untrusted back-end DBMS.
3.3 Operating System Providing Access Control
This approach (see Figure 5), also known as the Hinke-Schaefer approach, utilizes the underlying trusted operating system to perform the access-control mediation. No access-control mediation is performed by the DBMS. The DBMS objects (e.g., tuples) are aligned with the underlying operating system objects (e.g., files). Thus, Secret tuples are stored in Secret files and Top Secret tuples are stored in Top Secret files. With this approach there is no single DBMS that has access to the data in the database. There is an instantiation of the DBMS for each security level. The advantage of this approach is that it is simple and secure. The disadvantage is that performance will increase with the number of security levels. Note that this approach is also called the single kernel approach.
Figure 5 Operating systems providing mandatory access control.
3.4 Kernel Extensions Architecture
This approach (Figure 6) is an extension of the single kernel approach. The underlying operating system is utilized to provide the basic MAC and DAC mediation. However, the MLS/DBMS will supplement this access mediation by providing some additional access-control mediation. For example, the MLS/DBMS might provide context-dependent DAC on views. This approach differs from the trusted subject approach because the policies enforced by the MLS/DBMS do not depend on those of the operating system. An example of this architecture is that of LOCK Data Views system.
Figure 6 Kernel extensions architecture.
This approach has the same performance problems associated with the single kernel approach. However, because it provides more sophisticated access-control mechanisms, it could address some real-world access control needs.
3.5 Trusted Subject Architecture
This approach (Figure 7), also sometimes called dual kernel-based architecture, does not rely on the underlying operating system to perform access-control mediation. The DBMS performs its own access mediation for objects under its control. Thus, access to DBMS records is mediated by the trusted DBMS. The architecture is referred to as a trusted subject approach because the DBMS is usually a trusted subject (or process) hosted on top of the operating system. Essentially, the DBMS has access to the data in the database.
Figure 7 Trusted subject architecture.
The advantage of this architecture is that it can provide good security, and its performance is independent of the number of security levels involved. The disadvantage is that the DBMS code that performs access mediation must be trusted. This means that a large amount of trusted code may be needed for this approach.
3.6 Distributed Architecture
In this approach, there are multiple untrusted back-end DBMSs and a single trusted front-end DBMS. Communication between the back-end DBMS occurs through the front-end DBMS. There are two main approaches to this architecture. In one approach each back-end DBMS has data at a particular level and operates at that level (Figure 8). That is, the back-end DBMS at the Secret level will manage the Secret data and the back-end DBMS at the TopSecret level will manage the TopSecret data. We refer to this as the partitioned approach. With the second approach (Figure 9), lower-level data is replicated at the higher levels.
Figure 8 Distributed architecture: partitioned approach.
Figure 9 Distributed architecture: replicated approach.
Thus, the Secret DBMS will manage the Secret data, the Confidential data, and the Unclassified data. The Confidential DBMS will manage the Confidential data and the Unclassified data. We refer to this second approach as the replicated approach.
With the partitioned approach the trusted front end is responsible for ensuring that the query is directed to the correct back-end DBMS as well as for performing joins on the data sent from the back-end DBMSs. Because the query itself could contain information classified higher than the backend DBMS (such as the values in the where clause of the query), this approach suffers from a potentially high signaling channel. This is because queries are sent to the DBMSs 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 DBMS. Because only the DBMS operating at the same level as the user are queried, this approach does not suffer from the signaling channel of the first approach. Furthermore, this approach does not require front-end DBMS to perform the join operations. However, because the data is replicated, the trusted front end must ensure consistency of the data maintained by the different DBMS.
4 Summary and Directions
This chapter has provided an overview of mandatory access control and policies for MLS/DBMSs as well as described a taxonomy for the designs of MLS/DBMs. We first described the differences between access control in operating systems and access control in DBMS. Then we provided an overview of the Bell-LaPadula security policy and its adaptation for MLS/DBMSs. Finally we provided a detailed overview of various security architectures for MLDS/DBMS. These include integrity lock, operating system providing access control, kernel extensions, trusted subject, and distributed architectures. We discussed the advantages and disadvantages of each architecture. Several research prototypes and commercial products have been developed based on these architectures.
Although interest in MLS/DBMS is not as high as it was in the 1980s and 1990s, these systems are still being used for various applications. Therefore, we need to focus on the evaluation of various architectures especially based on features such as performance, usability, and extensibility. That is, we want the systems to be efficient, usable, and also extensible as new technologies are developed. In summary, there is still a lot to be done on the designs of MLS/DBMS.