The Seaview Security Project Computer Science

This paper talks about the SeaView multilevel security database model that was started in the year 1987 by the SRI international in collaboration with Oracle and Gemini Computers. The SeaView project was a three-year program to create the design of a multilevel secure relational database system that meets the criteria for Class Al of DOD. The underlying trusted computing base used in SeaView project is GEMSOS. The most significant contribution of SeaView is the realization that multilevel relations must only exist at a logical level and can be decomposed into single-level base relations. The architectural approach taken by the SeaView project is to implement the entire DBMS on top of the commercially available Gemsos TCB. [6]

Class A1 of DOD

Department of Defense has a security rating called class A1 that is defined as the "Verified Design". A system to be in Class A1 criteria, it should satisfy the following requirements:

It should satisfy the reference monitor criteria, that is it should mediate all accesses of subjects to objects, it should be tamperproof, and should be small enough to be subjected to analysis and test.

It must be structured in a way to exclude the code that is not necessary for the security policy enforcement.

Security Administrator role is defined

Automated imminent intrusion detection, notification and response

Overall it should have a formal design and verification techniques including a formal top level specifications

The SeaView Design

In pursuit of Class A1 assurance, in SeaView the design approach is built on the notion of a reference monitor for mandatory security. SeaView provides the user with the basic abstraction of a multilevel relation in which the individual data elements are individually classified. This design approach implements multilevel relations as views stored over single level relations, transparent to the user. The single-level relations are stored in segments managed by an underlying mandatory reference monitor. This underlying mandatory reference monitor performs a label comparison for subjects and the segments for which they request access, to decide whether to grant access. The access class of any particular data element in a multilevel relation is derived from the access class of the single-level relation in which the data element is stored, which in turn matches the access class of the segment in which it is stored, which is known to the reference monitor. Thus, labels for each individual data element do not have to be stored, as was supposed prior to SeaView. [5]

In SeaView, every database function is carried out by a single-level subject. Thus, a database system subject, when operating on behalf of a user, cannot gain access to any data whose classification is not dominated by the user's clearance. The use of only single-level subjects for routine database operations provides the greatest degree of security possible and considerably reduces the risk of disclosure of sensitive data. This approach means that there must be at least one database server instance for each active access class. Thus, the database system consists of multiple database server instances that share the same logical database.

Discretionary Access Controls

Discretionary access controls (DAC) are based on the concepts of a set of security objects O, a set of security subjects S, a set of access privileges T defining what kind of access a subject has to a certain object, and in order to represent content-based access rules a set of predicates P.

The tuple is called access rule and a function f is defined to determine if an authorization f(o,s,t,p) is valid or not:

f: OSTP {True, False}

For any , if f(o,s,t,p) evaluates into True, subject s has authorization t to access object o within the range defined by predicate p.

Delegation of rights

An important property of discretionary security models is the support of the principle of delegation of rights where a right is the (o,t,p)-portion of the access rule. A subject si who holds the right (o,t,p) may be allowed to delegate that right to another subject sj (i!=j).

Access Control Matrix

Most systems supporting DAC store access rules in an access control matrix. In its simplest form the rows of the matrix represent subjects, the columns represent the objects and the intersection of a row and a column contains the access type that subject has authorization for with respect to the object.

In Discretionary security instead of authorizing a user to the base relations of a system the information of the access control matrix is used to restrict the user to a particular subset of the data available.

Trojan Horse attacks when using DAC

In systems supporting DAC the identity of the subjects is crucial, and if actions can be performed using another subject's identity, then DAC can be subverted. A Trojan Horse can be used to grant a certain right (o,t,p) of subject si on to sj (i!=j) without the knowledge of subject si. Any program which runs on behalf of a subject acts with the identity of the subject and therefore has all of the DAC access rights of the subject's processes. If a program contains a Trojan Horse with the functionality of granting access rules on to other users this cannot be restricted by discretionary access control methods.

Model Layers

The SeaView security model is, designed with two model layers namely the MAC model, which is the inner layer, and the TCB model, which is the outer layer

Trusted Computing Base

The trusted computing base is everything in the computer system that provides secure environment. The trusted computing base is a set of hardware, software and procedural components that enforces security policy. In order to break the security policy an attacker should subvert one or more of them. The TCB model is a formal statement of the SeaView discretionary security policy and the supporting policies for labeling, data consistency, sanitization, and reclassification. The model includes a multilevel relation that includes real relations, snapshots, views, keys, relational expressions, and databases. It includes the application-independent integrity constraints of the multilevel relational data model and requirements for labeling derived data. It models the different relation instances seen by subjects of different access classes. It also includes application-dependent constraints (on classes and values), transactions, and discretionary access controls. [3]

The GEMSOS TCB used in SeaView provides discretionary access control lists for data objects (such as files), for program objects (such as source code and object code files, including predefined queries), and for the basic repositories in which databases are stored. A user identifier, group identifier, and environment identifier (user groups) are maintained for each executing subject, which is set when the subject is activated. Read, write, and execute access modes are provided. The GEMSOS discretionary security mechanisms are used to control user and group access to entire databases.

Mandatory Access Controls

Mandatory security models in addition to the DAC are concerned with the flow of information within a system. Mandatory security requires that security objects and subjects are assigned to certain security levels represented by a label. The label for an object o is called its classification (class (o)) and a label for a subject s is called its clearance (clear(s)). The classification represents the sensitivity of the labeled data while the clearance of a subject its trustworthiness to not disclose sensitive information to others. A security label consists of two components: a level from a hierarchical list of sensitivity levels or access classes (for example: top secret > secret > confidential > unclassified) and a member of a non-hierarchical set of categories, representing classes of object types of the universe of discourse.

Mandatory access control (MAC) requirements are often stated based on Bell and LaPadula (1976) and formalized by two rules. The first (simple property) protects the information of the database from unauthorized disclosure, and the second (*-property) protects data from contamination or unauthorized modification by restricting the information flow from high to low.

(1) Subject s is allowed to read data item d if clear(s)class(d)

(2) Subject s is allowed to write data item d if clear(s)class(d)

There is a lot of confusion that has arisen about the fact that in mandatory systems it is also necessary to include strong controls over who can write which data in systems with high security requirements. The reason behind it is that a system with high security needs must protect itself against attacks from unauthorized as well as from authorized users.

Prevention of Trojan horse attack using MAC

There are several ways authorized users may disclose sensitive information to others. This can be done by mistake, as a deliberate illegal action, or the user may be tricked to do so by a Trojan horse attack. The simplest technique to disclose information by an authorized user is to retrieve it from the database, to copy it into an 'owned' object, and to make the copy available to others. To prevent from doing so, it is necessary to control the ability of the authorized user to make a copy (which implies the writing of data). In particular, once a transaction has successfully completed a read attempt, the protection system must ensure that there is no write to a lower security level (write-down) that is caused by a user authorized to execute a read transaction. As the read and write checks are both mandatory controls, a MAC system successfully protects against the attempt to copy information and to grant the copy to unauthorized users. By not allowing higher classified subjects to 'write-down' on lower classified data information flow among subjects with different clearances can efficiently be controlled. As covert storage channels require writing to objects the *-property also helps to limit leakage of information by these hidden paths.

Integrity Rules used in SeaView model

Normally relational data model includes two integrity rules namely Entity integrity and referential integrity. In addition to these two rules, a SeaView project also includes a new rule named polyinstantiation integrity. All these rules should be applied to each access class that is every instance of a multilevel relation should satisfy these rules.

Entity Integrity

According to entity integrity, no tuple in a relation can have null values for any of the primary key attributes. Hence, to satisfy this condition all the elements forming the primary key must all have the same access class. Otherwise, a subject whose access class is lower than that of the highest key element would see null values for some of the elements forming the key. In addition, the access classes of all other elements in the tuple must dominate the access class for the primary key. If the class of some element in the tuple did not dominate the primary key class, then a subject operating at the element's access class could not uniquely select that element.

Referential Integrity

According to referential integrity, every secondary key must reference a tuple that exists in some other relation where the key is primary. In a multilevel database, this means that a secondary key element cannot reference a tuple with a higher or noncomparable access class because the referenced tuple would appear to be nonexistent at the access class of the reference. Multilevel referential integrity requires that if a foreign key is visible at a given access class, then a tuple containing the referenced primary key must also be visible at that access class, and that the class of the foreign key element must equal the class of the referenced primary key.

Polyinstantiation Integrity

Polyinstantiation integrity specifies that there must never be two tuples with the same primary key unless they represent polyinstantiated tuples or elements and controls the effects of polyinstantiation.

Polyinstantiation

Unlike the standard relational model, which prohibits multiple tuples with the same primary key, in the SeaView model, a multilevel relation can have multiple tuples with the same primary key data value(s), but different access classes for either the key value(s) or for other data elements in the tuples. These tuples are referred to as polyinstantiated data. Polyinstantiation refers to the simultaneous existence of multiple data objects with the same name, where the multiple instantiations are distinguished by their access classes. Polyinstantiation is necessary, as we will see below, in order to hide the actions of high subjects from low subjects, thereby preventing signaling channels.

Polyinstantiated tuples (PITS) are tuples identified by a primary key and associated key class, so that the same multilevel relation may contain several tuple instances for a primary key value corresponding to different access classes.

A polyinstantiated tuple arises whenever a subject inserts a tuple that has the same primary key value as an existing but invisible (more highly classified) tuple. The effect of the operation is to add a second tuple to the relation, whose primary key is distinguishable from the first by its access class. Although the polyinstantiation is invisible to this subject, subjects at the higher access class can see both tuples. To illustrate, if an unclassified subject adds a tuple for flight number 1 125 to the unclassified

relation shown in Fig. 2, then the outcome, as seen by a SECRET subject, is as shown in Fig. 3.

Polyinstantiated elements (PIES) are elements identified by a primary key, key class, and element class (in addition to the attribute name), so that there may be multiple elements for an attribute that have different access classes, but are associated with the same (primary key, key class) pair.

A polyinstantiated element arises whenever a subject updates what appears to be a null element in a tuple, but which actually hides data with a higher access class. In this case, the update has the effect of creating a polyinstantiated element for the tuple. A polyinstantiated element can also arise when a high subject updates a low element-instead of overwriting the low element value, a PIE is created. We model PIE'S as separate tuples.

To illustrate, if our unclassified subject now replaces the perceived null value

for the destination for flight 75 (see Fig. 2) with the value

"paris," the outcome, as seen by a SECRET subject, is

as shown in Fig. 4. Note, however, that the unclassified

subject does not see two flights numbered 75-the unclassified

subject's view of the relation is as shown in Fig. 5.

Article name: The Seaview Security Project Computer Science essay, research paper, dissertation