LIMITATIONS OF DISCRETIONARY CONTROLS

The standard access controls of SQL are said to be discretionary because the granting of access is under user control. Discretionary controls have a fundamental weakness, however. Even when access to a relation is strictly controlled, a user with SELECT access can create a copy of the relation, thereby circumventing these controls. Furthermore, even if users can be trusted not to engage deliberately in such mischief, programs infected with Trojan horses can have the same disastrous effect.

For example, in the following GRANT operation:

          TOM: GRANT SELECT ON EMPLOYEE TO DICK

Tom has not conferred the GRANT option on Dick. Tom’s intention is that Dick should not be allowed to further grant SELECT access on EMPLOYEE to other users. However, this intent is easily subverted as follows. Dick creates a new relation, COPY-OF-EMPLOYEE, into which he copies all the rows of EMPLOYEE. As the creator of COPY-OF-EMPLOYEE, Dick can grant any privileges for it to any user. Dick can therefore grant Harry access to COPY-OF-EMPLOYEE as follows:

          DICK: GRANT SELECT ON COPY-OF-EMPLOYEE TO HARRY

At this point, Harry has access to all the information in the original EMPLOYEE relation. For all practical purposes, Harry has SELECT access to EMPLOYEE, so long as Dick keeps COPY-OF-EMPLOYEE reasonably up to date with respect to EMPLOYEE.

The problem, however, is actually worse than this scenario indicates. It portrays Dick as a cooperative participant in this process. For example, it might be assumed that Dick is a trusted confidant of Tom and would not deliberately subvert Tom’s intentions regarding the EMPLOYEE relation. But if Dick were to use a text editor supplied by Harry, which Harry had programmed to create the COPY-OF-EMPLOYEE relation and execute the preceding GRANT operation, the situation might be different. Such software is said to be a Trojan horse because in addition to the normal functions expected by its user it also engages in surreptitious actions to subvert security. Thus, a Trojan horse executed by Tom could actually grant Harry the privilege to SELECT on EMPLOYEE.

Organizations trying to avoid such scenarios can require that all software they run on relational data bases be free of Trojan horses, but this is generally not considered a practical option. The solution is to impose mandatory controls that cannot be violated, even by Trojan horses.

MANDATORY ACCESS CONTROLS

Mandatory access controls (MACs) are based on security labels associated with each data item and each user. A label on a data item is called a security classification; a label on a user is called security clearance. In a computer system, every program run by a user inherits the user’s security clearance.

In general, security labels form a lattice structure. This discussion assumes the simplest situation, in which there are only two labels — S for secret and U for unclassified. It is forbidden for S information to flow into U data items. Two mandatory access controls rules achieve this objective:

1.  Simple security property. A U-user cannot read S-data.

2.  Star property. A S-user cannot write U-data.

Some important points should be clearly understood in this context. First, the rules assume that a human being with S clearance can log in to the system as a S-user or a U-user. Otherwise, the star property prevents top executives from writing publicly readable data. Second, these rules prevent only the overt reading and writing of data. Trojan horses can still leak secret data by using devious means of communication called covert channels. Finally, mandatory access controls in relational data bases usually enforce a strong star property:

•  Strong star property. A S-user cannot write U-data, and a U-user cannot write S-data.

The strong star property limits users to writing at their own level, for reasons of integrity. The (weak) star property allows a U-user to write S-data. This can result in overwriting, and therefore destruction, of S-data by U-users. The remainder of this chapter will assume the strong star property.

Labeling Granularity

Security labels can be assigned to data at different levels of granularity in relational data bases. Assigning labels to entire relations can be useful but is generally inconvenient. For example, if some salaries are secret but others are not, these salaries must be placed in different relations. Assigning labels to an entire column of a relation is similarly inconvenient in the general case.

The finest granularity of labeling is at the level of individual attributes of each tuple or row or at the level of individual element-level labeling. This offers considerable flexibility. Most of the products emerging offer labeling at the level of a tuple. Although not so flexible as element-level labeling, this approach is definitely more convenient than using relation- or column-level labels. Products in the short term can be expected to offer tuple-level labeling.

MULTILEVEL DATA BASE ARCHITECTURES

In a multilevel system, users and data with different security labels coexist. Multilevel systems are said to be trusted because they keep data with different labels separated and ensure the enforcement of the simple security and strong star properties. Over the past fifteen years or so, considerable research and development has been devoted to the construction of multilevel data bases. Three viable architectures are emerging:

1.  Integrated data architecture (also known as the trusted subject architecture).

2.  Fragmented data architecture (also known as the kernelized architecture).

3.  Replicated data architecture (also known as the distributed architecture).

The newly emerging relational data base products are basically integrated data architectures. This approach requires considerable modification of existing relational DBMSs and can be supported by DBMS vendors because they own the source code for their DBMSs and can modify it in new products.

Fragmented and replicated architectures have been demonstrated in laboratory projects. They promise greater assurance of security than does the integrated data architecture. Moreover, they can be constructed by using commercial off-the-shelf DBMSs as components. Therefore, non-DBMS vendors can build these products by integrating off-the-shelf trusted operating systems and non-trusted DBMSs.