This paper describes a relational database model for the provision of a multilevel database security system based on views. Views have been recognized as a mechanism for providing security since the introduction of the CODASYL DBTG Report. However, the subschema mechanism in CODASYL systems provides only very elementary security, in the sense that records and sets to which an individual user does not have access are not included in the subschema definition and consequently will not be recognized by the application program. The view mechanism available in most relational systems today is much more powerful. Above all it can be used to define an arbitrary set of stored or derived data through, for example, SQL statements. The ability to handle derived data is particularly significant in the context of the provision of security; on the whole, ensuring the security of stored data is a simpler and indeed better understood task.

In this paper Denning and her coauthors exploit the view facility in order to provide a sophisticated multilevel security system aimed at meeting the Department of Defense Trusted Computer Systems Evaluation Criteria for Class A1. The authors assume familiarity with these criteria, which is a drawback, especially for non-United States readers. The results reported in the paper represent the preliminary efforts of a three-year research program and hence there are still a number of aspects that have yet to be considered. However, the proposed system has many obvious advantages, not the least the fact that it uses existing facilities within the DBMS (view definition) in order to provide security. Extensions to standard SQL for the definition of various constraints are proposed.

An important tenet of the provision of security at any level is that an individual trying to access an unauthorized data item should have the request refused in such a way that the user cannot even infer from the system’s response to the request that the data item requested even exists. This of course has ramifications in, for example, the area of primary keys. A user may have data dependent access privileges (including insertion) for a subset of tuples in the relation, but no access privileges for the remaining tuples in that relation. Hence if the user inserts a record into a relation that happens to have the same primary key as a tuple to which he or she does not have access, the user cannot be told this because otherwise the information that the unauthorized tuple exists would be disclosed. To overcome this problem, the authors propose to extend the concept of primary key to incorporate the access class. Hence the two tuples would be regarded as different if they belonged to different access classes even though their primary keys are the same. Much of the theory of Relational Database Management Systems is based on the concept of a primary key, and I wonder whether by altering the nature of the primary key, there could be problems that the authors have not yet foreseen. It certainly complicates the processing of relations--how, for example, would you define a join?

The proposal is an interesting one and by using the view definition facility with its powerful support for semantic rules, many problems, such as single trackers, can be dealt with quite simply. I await with interest the final system and in particular want to see how transparent the security system can be made to the end-users.