Understanding Relational Databases and Assessing Their Security - High-Performance Web Databases: Design, Development, and Deployment - page 768

Exhibit 56-3. Sample labels.

associated with that row of data, access to that data will be denied regard-
less of any discretionary access rules that might otherwise permit access.

For example, a company might classify its data as being either propri-
etary, company confidential, or public. Each of these hierarchical classifi-
cations constitutes a security level within the database. Within each level,
however, data can be further divided into descriptive, nonhierarchical cat-
egories. One category might identify proprietary data that belongs to a cer-
tain special project; another category might identify the department that
controls the proprietary information. It is the combination of security level
and category that forms the sensitivity label associated with the data
object. Therefore, as shown in Exhibit 3, access to a relational database
row labeled PROPRIETARY:FINANCE would be restricted to those users
with sufficient clearance to access proprietary information belonging to
the finance department.

Under a multilevel secure system, sensitivity labels are stored with the
data object and can be changed only by users who have certain powerful
mandatory access control privileges. Similarly, only users with such privi-
leges are permitted to transfer access authority from one user to another;
end users cannot transfer access privileges at their discretion. Mandatory
access control privileges must be carefully administered and monitored to
protect against their misuse.

Security Conflicts in Multilevel Database Applications

The use of multilevel secure data systems can create conflicts between
data confidentiality and integrity. The enforcement of integrity rules can
create covert channels for discovering confidential information and, in gen-
eral lead to conflicts between other business rules and security policies.

3

For example, enforcement of entity integrity requires that each database
row be identified by its primary key, which cannot be a null value. A conflict
between data confidentiality and integrity can arise if a user with a low-level
access classification (e.g., unclassified) attempts to add a primary key that,
in fact, already exists at a higher classification level (e.g., confidential).
(A primary key at this high security level is not visible to an unclassified
user.) If the database system permits the addition of this duplicate key,