Sebery J.Cryptography.An introduction to computer security.1989

Name-mapping data structures for these blocks is based on the structure memory concept, in which a mass memory holds the information making up the database and contains only update invariant name-mapping data structures. The structure memory and the mass memory in the DBC are implemented as PCAMs. Name-mapping data structures are simpli ed using the concept of area pointers. A given area pointer shows which PCAM partitions holds a required data item, and no modi cation needs to be done on an area pointer in the case that data items are moved.

In order to minimize the diÆculties met during the modi cation of namemapping data structures a fast look aside bu er is employed. Before any chance is recorded permanently in the structure memory, it is rst recorded in this bu er and is used to satisfy subsequent commands.

To overcome the bottleneck found on many database systems that employ software modules, the DBC has taken the approach of functional specialization. Here, components are designed individually to adapt to their speci ed functions. The DBC has seven major specialized components. These are the keyword transformation unit (KXU), the structure memory (SM), the mass memory (MM), the structure memory information processor (SMIP), the index translation unit (IXU), the database command and control processor (DBCCP), and the securitylter processor (SFP). The system operation consist of two \loops," namely, the structure loop and the data loop, which have the the DBCCP in common. The incoming request from the Program Execution Unit (PES) is passed through the KXU that converts keywords into their internal form, and structural information about the database is retrieved and maintained by the SM. Set operations on the structural information is performed by the SMIP. Both the SM and the SMIP are implemented using PCAMs. The structural information from the SMIP is then decoded by the IXU and the results returned to the DBCCP. The data retrieval and update is then performed in the data loop. The MM contains the database and the SFP performs the necessary security checks.

Although the DBC initially employed the relational model, simulation studies shows that it is also suitable for the network and hierarchical data models [235].

542 16 DATABASE PROTECTION AND SECURITY

16.5 Database Views

The concept and implementation of views in the broad area of database systems has been a topic of research for a number of years [79, 498, 437, 544, 274]. Interest in the use of views for purely security purposes only began in the early 1980's. One of the earliest uses of views was by GriÆths and Wade [221] in IBM's System R as a form of access control. This early work, however, concentrated on a single security classi cation and attempted mainly to solve the problem of grant propagation in a multiuser database system. The use of views for multilevel security in database systems was independently suggested in 1983 by Claybrook [98] and by the Summer Study on Multilevel Database Management System coordinated by the US Air Force Summer Studies Board [104].

In order to understand the possible uses of views as security objects, it is useful to de ne views and to brie y look at its related terminology. Although views are not strictly de ned over the relational data model, the best examples can be given using this data model and the syntax of the Structured Query Language or SQL [121]. The general form of an SQL query is the following:

select att1; att2; : : : ; attn from rel1; rel2; : : : ; relm where pred

Here, atti are the attributes, reli the database relations, and pred is the predicate. The attributes can also be replaced by a (*), meaning that the whole tuple (record) with all its attributes are to be retrieved.

A view can be de ned to be a preset or prede ned named retrieval query that creates a virtual relation over base relations. The view or virtual relation is not stored in the database, whereas the base relations are the underlying data stored in the database. Once created, a view can be queried as if it were a true relation. Views can be built upon other views, and so on. For example, in [98] Claybrook presents an architecture whereby an internal view is de ned over the database, then a conceptual view is in turn de ned over the internal view andnally the multiple user-de ned views are de ned over the conceptual view.

Using the SQL notation, the following is an example of the creation of a view V , which is then queried by a user:

create view V as

select att1; att2; : : : ; attn from rel1; rel2; : : : ; relm

where predview def

select atti1; atti2; : : : ; attik from V

where preduser

During query processing, the user query over view V is resolved internally into:

select atti1; atti2; : : : ; attik from rel1; rel2; : : : ; relm

where predview def and preduser

There are a number of concepts and terminology that are often used in discussing views and database security in general. Following the notations found in Wilson [535] and Denning et al. [143] these are the following:

{A security level is a pair (H; S) where H is a hierarchical security classi cation and S is a set of categories or compartments [535].

Examples of the classi cation are Con dential < Secret < Top Secret, and examples of categories are Crypto, NATO and others. An alternate notation is given in [143] where a security level is the pair

hSecrecyLevel, SecurityCategoryi

which is also de ned to be the secrecy component of an access class. The integrity component of an access class is given as

hIntegrityLevel, IntegrityCategoryi

{ The security level (H1; S1) dominates the security level (H2; S2) or

(H1; S1) (H2; S2)

when H1 H2 and S2 S1.

That is, a given security level L1 dominates the security level L2 when level L1 is used, classify data that is at least as sensitive as data classi ed as L1. When L1 strictly dominates L2 (L1 > L2) we have that (L1 L2) and (L1 6= L2). Hence the symbol denotes partial ordering [535]. Equivalently,

544 16 DATABASE PROTECTION AND SECURITY

access classes [143] can be seen as an element of a lattice structure having the

partial ordering, where access class L1 dominates (or strictly dominates) another access class L2.

{A subject is an active entity that accesses objects in accordance with a security policy.

In the case of views in databases, the subject may be a process executing on behalf of a user, and the objects are various views de ned over the base relations and other views [535]. The subject or user has clearance or an associated access class [143], and the clearance (or access class) of a subject must dominate the classi cation (or access class) of the data before the subject has access to the data.

16.5.1 Advantages and Disadvantages of Views

There are a number of advantages to use views for security objects in database systems. The rst and foremost is the fact that views express the context of the data over which it is de ned, and it is important that both the context and the data itself need to be protected. In its simplest form views present a subset of the database to the user, be it whole tuples or whole elds attributes. Any change in the underlying base relation does not require a corresponding modi cation to the view de nition over that base relation. Thus, views are very much static even while the database is dynamically changing. This advantage is derived from the fact that views can be de ned independently of the logical structure and design of the database [98].

Views also provide content-dependent security where certain eld (or attribute) values can be placed in the view de nitions and the records (or tuples) containing those values can be suppressed from certain users or group of users. The opposite e ect can be achieved by allowing only tuples containing certain attribute values to be displayed to the user. Content-dependent security further implies that only correct values or values within a given range can be inserted into the database via views. In this way users have less chance of inserting inappropriate values by chance or deliberately.

Another advantage of views is that labeling of attributes and tuples can be done by creating a separate attribute containing the security labels. Thus, the labels can be stored as part of a relation or as a separate relation, and its existence can be hidden away from the user through the use of views. Hence,

it is clear that the database system need not have any special mechanism to coordinate labeling of attributes and tuples. An example of an attribute to store labels is the following [535]:

create view Vlevel L as select *

from R

where LabelAttribute L

In this example R is the relation while LabelAttribute is the attribute of R containing the labels of the tuples in R. If the views are de ned using the SQL syntax then conditional expressions can be included in the view de nition:

create view Salariesunclassified as select Name, DepartmentNumber,

UnclassifiedSalary = if Salary 10000 then Salary

else F (Salary) from Employees

where F can be a function that performs some operation on the Salary attribute. F can also be a sanitization operation or function [143] that is de ned to be a computation that takes input from a source and outputs data that is less sensitive that the source. Besides sanitization functions, other built-in functions can also be used inside the view de nition. An example of these are functions that return machine time and date, and user identi cation.

Although views have many advantages, there are some shortcomings. View de nitions may contain errors, and the database upon which the views are de ned may also contain errors [535]. If content dependence is used in the de nition, then errors in the database may cause the downgrade of whole tuples that are accessed by the users. The complexity of view de nitions may also result in the overhead in computing resource usage. Another possible threat comes from users or trojan horses that attempt to deduce the view de nition of data of higher security classi cation by doing various insert operations and retrievals through the views. If an inserted data cannot be retrieved again by the user due to the view de nition, then the user has gained some information through inference about the view de nition. In general, the advantages of views

546 16 DATABASE PROTECTION AND SECURITY

outnumber its disadvantages, and views do present some possibilities for high level protection.

16.5.2 Completeness and Consistency of Views

Although views may contain visible errors in the syntax of their de nition, of more concern and interest are the errors arising from the con ict of two or more syntactically correct view de nitions. In such cases, one view de nition may present some conditions or constraints that must be observed in order for data to be accessed through that view, while another view de nition may relax or even contradict the constraints of the rst view de nition.

Denning et al. [143] distinguishes between a view that retrieves or updates data and a view that classi es data. The rst type is referred to as access views while the later is refered to as classi cation constraints. Access views can be used to retrieve data through the user's clearance. The base relation that contains the required data is permitted to have a higher security clearance. Classi cation constraints are views that specify access classes and the relationship between actual data in the relation and other data derived from it. In this way views as classi cation constraints can be used to manage content dependencies and context dependencies, to control inference by the users and to perform sanitization of data. A sanitization rule ensures that the access class of the view output (target) is dominated by the least upper bound of the access class of the view input (source).

Classi cation constraints must be consistent and complete. A set of classi cation constraints is consistent when no two constraints de ne con icting classes and they both must be simultaneously satis ed. A set of classi cation constraints is complete when an access class is de ned for each valid data element. A more speci c de nition given in Akl and Denning [4] is the following:

Assume that a multilevel relation R is modeled by the scheme

R(A1; C1; A2; C2; : : : ; An; Cn);

where Ci is the classi cation attribute holding the access class labels of data attribute Ai. A classi cation constraint is then a rule of the form S = (R; A; E; L) that is interpreted as if E then class(R:A) = L, where R is the relation, A is one or more data attributes in R, E is an optional expression and L is the access class.

A set of classi cation constraints is consistent when any two constraints Si and Sj are consistent, which in turn requires one of the following four conditions to be true:

1.Li = Lj { both constraints assign the same access class.

2.Ai \ Aj = 0 { constraints Si and Sj apply on disjoint attribute sets.

3.Ei \ Ej = 0 { occurs when Si and Sj cannot be simultaneously satis ed.

4.Ei \ Ej \ D = 0 { constraints Si and Sj never simultaneously satisfy all integrity constraints.

Here D is the intersection of all m integrity constraints I1; : : : ; Im in the database. A set of classi cation constraints is complete when for every instance of the database in D, each element is assigned an access class by at least one constraint.

Akl and Denning [4] also present an algorithm based on computational geometry to check for consistency, with a complexity of the order of O(Nn2 (g+m2)), where N is the number of relations, n the number of classi cation constraints, m the number of integrity constraints, and g is the number of attributes in each relation. An algorithm to check for completeness is also presented in [4], with a complexity of the order O(Mn), with M being the number of attributes in the database.

The algorithms in [4] for secure views are computationally feasible when the constraints are simple and deal only with numeric data. In [535], Wilson proposed the idea of atomic views which is a small set of views on which secure views can be built. For a relation R, a view R=L is de ned for each security level L that includes exactly the tuples of the relation R classi ed at level L. Similarly, view R L is de ned to include tuples of R that are dominated by L. Then, for each hierarchical classi cation and for each category Ci, an atomic view R Ci is de ned to consist of the set of tuples whose levels dominate Ci. Wilson proposes that atomic views should be de ned by the trusted database administrators, while the DBMS should automatically create secure views based on the atomic views. Atomic views guarantees that completeness and consistency are achieved in de ning secure views. Atomic views in [535] are more general than secure views in [4] as they are not restricted to numerical values.

548 16 DATABASE PROTECTION AND SECURITY

16.5.3 Design and Implementations of Views

Although interest in the use of views and research into formal methods of describing views started in the 1980s, only few projects have been dedicated completely to investigating views for database security. One major project whose results have shaped much of the opinion on secure views is the SeaView project.

SeaView. The SeaView project has its roots in the Summer Study on Multilevel Data Management Security held by the Committee on Multilevel Data Management Security of the US Air Force Studies Board [104]. The project was a three-year joint work by SRI International and Gemini Computers. Its aim is to design a multilevel secure database system ful lling the A1 class of secure systems as speci ed by the US Department of Defense Trusted Computer Systems Evaluation Criteria [146].

Within the three year period of its design, the project by Denning et al. has completed a security policy and interpretation [139], a multilevel relational data model [144, 314] that is an extension of the standard relational data model to accommodate labeling, a formal security policy model [140] and a formal toplevel speci cations [316] with its veri cation [528]. The project also contributed ideas on the assurance of multilevel database systems [313]. The SeaView models extends the relational data model by including in it mandatory security requirements and by supporting data consistency through application-dependent constraints. Data in the base relations and views are hidden from unauthorized users, with di erent users seeing di erent instances of a given relation. This multiple instances of the same objects or polyinstantiations have di erent access classes. Thus multiple tuples with the same primary key but di erent access classes can exist. Similarly, tuples may have multiple values, each having a di erent access class.

With respect to its architecture, SeaView has ensured that all components of the system that enforces mandatory security are to be isolated in a security kernel. The whole database system with all its support for multilevel relations is to be implemented on a general-purpose operating system kernel enforcing mandatory security policy at the single-level le and segments [313]. Each multilevel real relation is decomposed into the single-level relations de ned as single-level kernel objects. These single level relations are then later combined to provide the multilevel relations for the users. The reader is directed to Lunt et al. [316]

for a detailed discussion on the architecture and components of the SeaView implementation.

ASD Views. Another project on the implementation of views is ASD Views by the TRW Defense Systems Group [193]. The main aim in ASD Views is to achieve a suitably sized Trusted Computing Base (TCB) that meets the criteria for evaluation of class B2 and above. ASD Views is an attempt to solve the problem met when views are de ned to be objects of both mandatory and discretionary security in multilevel secure DBMSs. In particular, the major diÆculty in a view-based DBMS is that the TCB tends to become very large because views involves a great deal of the DBMS code. The requirement of a class B2 certi cation as speci ed in [146] is that only a small size TCB can be used. Thus, most view-based DBMS will face diÆculty in achieving certi cation above class B1.

The approach in SeaView [143] is to place the view mechanism over a reference monitor together with a trusted kernel. Each level of data is then physically stored on its own disk segment and the reference monitor must guarantee that only data with clearance dominated by the user's clearance is released. The main problem with this con guration is that the overall performance of the system rapidly degrades if the mechanism is used for large amounts of data.

ASD Views takes the simpler solution of restricting the query language that can be used in the view de nition. This limits the complexity of the view de nition but ensures that the TCB remains small. The view de nition only allows a subset of rows (tuples) and columns (attributes) from only one underlying base relation. Joins, aggregate functions, and arithmetic expressions are excluded. These restrictions allow the processing of the query that de nes a secure view to be done within the TCB perimeters without the need of the creation of other data structures commonly associated with queries. Thus within the TCB only a small number of data structures are created for any view de nition. Another important point is that ASD Views do not allow polyinstantiations so that the complexity of their implementations can be reduced.

The architecture of ASD Views consists of three general parts. The SQL Processor resides outside the TCB boundary, and it decomposes user queries into requests to read rows (tuples) from the secure views de ned by the TCB. These reduced queries are then handled by the Restricted View Processor followed by the Read/Write Row Interface, both of which reside inside the TCB

550 16 DATABASE PROTECTION AND SECURITY

boundary. The reader is directed to the work by Garvey and Wu [193] for more details.

16.6 Security in Distributed Databases

Although there is a considerable amount of research material dealing with aspects of distributed database systems and their design, research into the security aspects of distributed database systems and distributed systems in general have only began to take serious form and de nition during the last ve years. The amount of available research results that directly address security in distributed database systems is small, due not to the lack of interest in the topic on the part of researchers, but rather to the complexity of distributed systems in itself and the necessary groundwork in the security of centralized database systems before any consideration can be given to security in distributed databases.

Researchers have addressed the individual security needs of distributed databases as compared to the security of distributed systems in general [409, 331, 317]. The security of some issues and features of distributed databases have began to be analyzed, particularly those that have solid research background from the pure database research point of view.

Such an analysis is exempli ed by the work by Downing, Greenberg, and Lunt [161] where the security of serializable transactions has been considered. Two general assumptions that are useful for all distributed transactions have been suggested in this work:

{?-property { simply requires that a transaction must write only data whose access class equals the transaction class. This is a direct derivation from the Bell-La Padula security model [19, 20].

{Simple Security Property { requires that transactions must read only data whose access class is dominated by the transaction class. That is, the \readdown" rule must be observed.

Following these two assumptions the work in [161] proceeds to compare three concurrency control techniques that have been suggested in the pure database research literature, namely, two-phase locking, time-stamp ordering, and optimistic concurrency control. Out of these three concurrency control techniques, only optimistic concurrency control satis es the two assumptions, and together