A Multi-Purpose Implementation of Mandatory Access Control in Relational Database Management Systems Walid Rjaibi Paul Bird IBM Toronto Software Laboratory 8200 Warden Avenue Markham, Ontario Canada {wrjaibi, pbird}@ca.ibm.com Abstract access rules in the access plan it generates for an SQL query, and to prevent unauthorized Mandatory Access Control (MAC) implemen- leakage of data that could occur as a result of tations in Relational Database Management traditional optimization techniques performed Systems (RDBMS) have focused solely on by SQL compilers. Multilevel Security (MLS). MLS has posed a number of challenging problems to the database research community, and there has 1 Introduction been an abundance of research work to ad- dress those problems. Unfortunately, the use Mandatory Access Control (MAC) is a means of re- of MLS RDBMS has been restricted to a few stricting access to objects based on the sensitivity government organizations where MLS is of (as represented by a label) of the information con- paramount importance such as the intelligence tained in the objects and the formal authorization (i.e., community and the Department of Defense. clearance) of subjects to access information of such The implication of this is that the investment sensitivity[8]. A well-known implementation of MAC of building an MLS RDBMS cannot be lever- is Multilevel Security (MLS), which, traditionally, has aged to serve the needs of application domains been available mainly on computer and software sys- where there is a desire to control access to ob- tems deployed at highly sensitive government organi- jects based on the label associated with that zations such as the intelligence community or the U.S. object and the label associated with the sub- Department of Defense. The Basic model of MLS was ject accessing that object, but where the label first introduced by Bell and LaPadula[9]. The model access rules and the label structure do not nec- is stated in terms of objects and subjects. An object is essarily match the MLS two security rules and a passive entity such as a data file, a record, or a field the MLS label structure. This paper intro- within a record. A subject is an active process that duces a flexible and generic implementation of can request access to objects. Every object is assigned MAC in RDBMS that can be used to address a classification, and every subject a clearance. Classi- the requirements from a variety of application fications and clearances are collectively referred to as domains, as well as to allow an RDBMS to ef- labels. A label is a piece of information that consists of ficiently take part in an end-to-end MAC en- two components: A hierarchical component and a set terprise solution. The paper also discusses the of unordered compartments. The hierarchical compo- extensions made to the SQL compiler compo- nent specifies the sensitivity of the data. For example, nent of an RDBMS to incorporate the label a military organization might define levels Top Secret, Secret, Confidential and Unclassified. The compart- Permission to copy without fee all or part of this material is ments component is nonhierarchical. Compartments granted provided that the copies are not made or distributed for are used to identify areas that describe the sensitivity direct commercial advantage, the VLDB copyright notice and or category of the labeled data. For example, a mili- the title of the publication and its date appear, and notice is given that copying is by permission of the Very Large Data Base tary organization might define compartments NATO, Endowment. To copy otherwise, or to republish, requires a fee Nuclear and Army. Labels are partially ordered in and/or special permission from the Endowment. a lattice as follows: Given two labels L1 and L2, Proceedings of the 30th VLDB Conference, L1 >= L2 if and only if the hierarchical component Toronto, Canada, 2004 of L1 is greater than or equal to that of L2, and the 1010 compartment component of L1 includes the compart- a “security label” in the case of the latter. Unfor- ment component of L2. L1 is said to dominate L2. tunately, a MAC implementation in an RDBMS that MLS imposes the following two restrictions on all data strictly implements MLS fails to address privacy re- accesses: quirements for the following two main reasons. First, MLS labels include a hierarchical component that is • The Simple Security Property or “No Read Up”: not applicable in the case of privacy. Next, the MLS A subject is allowed a read access to an object security properties do not apply in the context of pri- if and only if the subject’s label dominates the vacy. For example, to read an object in MLS, the object’s label. subject’s compartment component must include that object’s compartment component (the simple security • The *-Property (pronounced the star property) or property). In privacy, the rule is exactly the opposite. “No Write Down”: A subject is allowed a write That is, if an object is tagged with the purposes mar- access to an object if and only if the object’s label keting and purchase, then a user accessing that object dominates the subject’s label. for the purpose of sending marketing information must be allowed to access that object. 1.1 Problem Statement Another application domain is private banking. In MAC implementations in Relational Database Man- private banking, country laws and regulations often re- agement Systems (RDBMS) have focused solely on quire to limit the amount of data that can be viewed MLS. MLS has posed a number of challenging prob- by a bank employee. For example, Swiss banking laws lems to the database research community, and there do not allow a Swiss bank employee located in Toronto has been an abundance of research work to address to access account information for customers based in those problems. There has also been three commercial Switzerland. Typically, banking applications code this MLS RDBMS offerings, namely, Trusted Oracle[16], fine-grained access control in the application itself, as Informix OnLine/Secure[17], and Sybase Secure SQL opposed to delegating this task to the RDBMS. Un- application-aware Server[20]. Unfortunately, the use of MLS RDBMS fortunately, this approach has made has been restricted to a few government organizations enterprise security policies a laborious and complex where MLS is of paramount importance such as the in- task. It also has the drawback of exposing the secu- telligence community and the Department of Defense. rity policies to the application programmers. If each In fact, very few commercial organizations need such customer account is tagged with a label indicating the type of security. The implication of this is that the in- geographical location of the customer and if each bank vestment of building an MLS RDBMS cannot be lever- employee can be assigned a label that also indicates aged to serve the needs of application domains where the geographical location of that employee (for exam- there is a desire to control access to objects based on ple, based on the system security context established the label associated with that object and the label as- when that employee logs on to the database), then an sociated with the subject accessing that object, but RDBMS that implements a form of MAC where the where the label access rules and the label structure database administrator could define the label struc- do not necessarily match the MLS two security rules ture and the label access rules could relieve the ap- and the MLS label structure (i.e., a hierarchical com- plications from implementing such fine-grained access ponent and a set of unordered compartments). The control policies. question that begs to be asked is therefore the follow- Moreover, the ever increasing enterprise demands ing: Do such application domains exist and, if so, what for more security has led to the emergence of label are they? security products that provide the ability to set up We contend that the answer to that question is an and control access based upon labels throughout an unequivocal yes. Privacy[19] is one example of such entire network from end-to-end. For example, such la- application domain. Generally, a privacy policy indi- bel security products have the ability to control the cates for which purposes an information is collected, network to decide whether or not a particular labeled whether or not it will be communicated to others, data row can be transmitted on a particular channel and for how long that information is retained before or be delivered to a particular workstation on that net- it is discarded. For example, a user cannot access a work. An important advantage of such label security customer record for the purpose of sending that cus- products is their ability to offer a centrally managed tomer marketing information if that customer did not tool for defining label access policies and for assign- agree to receive such information. Access to privacy- ing access labels to users as well as to other entities sensitive data can be regarded as analogous to access on the network. Traditional implementations of MAC to MLS data in the sense that in both cases there is in RDBMS (i.e., MLS) do not offer the required flex- a tag associated with the object being accessed and ibility to efficiently integrate with such label security the subject accessing that object. The tag represents products and to provide pervasive system coverage us- a “purpose” in the case of the former and represents ing a unified and centrally managed label access policy. 1011 Therefore, there is a need for a flexible and generic allow an RDBMS to efficiently take part in an end-to- implementation of MAC in RDBMS that can be used end MAC enterprise solution.