Trusted RUBIX TM. Version 6. Multilevel Security in Trusted RUBIX White Paper. Revision 2 RELATIONAL DATABASE MANAGEMENT SYSTEM TEL +1-202-412-0152

Trusted RUBIX TM Version 6 Multilevel Security in Trusted RUBIX White Paper Revision 2 RELATIONAL DATABASE MANAGEMENT SYSTEM Infosystems Technology, Inc. 4 Professional Dr - Suite 118 Gaithersburg, MD 20879 TEL +1-202-412-0152

1981, 2014 Infosystems Technology, Inc. (ITI). All rights reserved. Unpublished work. Commercial computer software and software documentation: Government users are subject to ITI's standard license agreement per DFARS 227.7203-3 or, in non-dod agencies where such protection is unavailable, to "restricted rights" under applicable FAR System clauses. Infosystems Technology, Inc. 4 Professional Dr - Suite 118 Gaithersburg, MD 20879 THIS DOCUMENTATION CONTAINS CONFIDENTIAL INFORMATION AND TRADE SECRETS OF INFOSYSTEMS TECHNOLOGY, INC. USE, DISCLOSURE, OR REPRODUCTION IS PROHIBITED WITHOUT THE PRIOR EXPRESS WRITTEN PERMISSION OF INFOSYSTEMS TECHNOLOGY, INC. FOR FULL DETAILS OF THE TERMS AND CONDITIONS FOR USING THE SOFTWARE, PLEASE REFER TO THE ITI-TRUSTED RUBIX USER LICENSE AGREEMENT. The information in this document is subject to change without notice and should not be construed as a commitment by ITI. Infosystems Technology, Inc. assumes no responsibility for any errors that may appear in this document. RUBIX is a trademark of Infosystems Technology, Inc. UNIX is a trademark of The Open Group. Microsoft is a trademark of the Microsoft Corporation. Printed in U.S.A.

Table of Contents OVERVIEW... 1 MLS LABELS... 1 DOMINANCE RELATIONSHIP... 2 INFORMATION FLOWS... 3 SECURITY LATTICE... 4 MLS ACCESS CONTROL RULES FOR SQL OPERATIONS... 6 MULTILEVEL DBMS OBJECTS... 7 TABLE SELECT EXAMPLE... 9 POLYINSTANTIATION... 10 CONCURRENCY CONTROL... 12 MLS OS-DBMS POLICY INTEGRATION... 14 APPENDIX A: FREQUENTLY ASKED QUESTIONS (FAQ)... 16

Overview 1 11 1 Multilevel Security is a Mandatory Access Control (MAC) policy designed to control the flow of information between subjects based upon their trustworthiness. In general information is allowed to flow from less trustworthy subjects to more trustworthy subjects. Subjects are assigned labels that represent their trustworthiness while objects are assigned labels that represent their sensitivity. These labels are used along with fixed Bell-La Padula rules to control operations. In general, Bell-La Padula rules allows subjects to read objects at lower labels and update objects at their label. The simple and static nature of the Bell-La Padula rules provides the potential for a higher assurance of correctness as compared to more complex and dynamic security policy models. Trusted RUBIX fully integrates the Multilevel Security policy into its DBMS, labeling all DBMS objects and controlling access to all SQL operations. In addition, Trusted RUBIX fully integrates with the Multilevel Security policy of the underlying operating system, providing coherent total-system security behavior. MLS Labels Central to the Multilevel Security policy is the MLS label, also known as a level. Each subject (e.g., a DBMS session open on behalf of a user) and object (e.g., a DBMS row) is assigned an MLS label. The MLS label assigned to a subject determines which operations the subject may perform. The subject label is also assigned to objects created by the subject. The MLS label assigned to an object determines which operations may be performed upon the object. Generally, a subject may read an object if the subject's label dominates (is "higher" than) the object's label and may update an object if the subject's label equals the object's label. MLS label's are composed of two distinct parts: the sensitivity (objects)/clearance (subjects) and the compartments. Compartments may also be known as categories. The sensitivity/clearance component of a label represents the degree to which information is securitywise sensitive (object's only) and the user's trustworthiness (subjects only). It frequently takes on a string form like "Top Secret" or "Unclassified." The compartments component of a label represents a user's "need to know." This usually refers to the information a user needs to operationally perform her duties. While they may be "cleared" or "trusted" to see other information, they have no operational need to see such data to perform their job responsibilities and, taking a conservative approach to security, the MLS policy denies them access. Trusted RUBIX labels its DBMS objects with the same MLS labels used by the underlying operating system. The following diagram gives sample MLS labels in Solaris 10 Trusted Extensions (TX) and SELinux formats. For SELinux, the MLS level is one of four components within its security context. The left-most part of each MLS label represents the sensitivity/clearance component while the right-most component represents the compartments. In both cases the MLS label may be configured to have a user-friendly string representation. SELinux MLS

label compartments may be specified as a comma separated list (e.g., c1, c5, c9) and as a range (e.g., c1.c3). Also note that a MLS label need not contain any compartments. 2 22 2 Figure 1: Sample MLS Labels Dominance Relationship The Multilevel Security policy uses an ordering relationship between labels known as the dominance relationship. Intuitively, we think of a label that dominates another as being "higher" than the other. Similarly, we think of a label that is dominated by another as being "lower" than the other. The dominance relationship is used to determine permitted operations and information flows. The dominance relationship is determined by the ordering of the Sensitivity/Clearance component of the label and the intersection of the set of Compartments.

Sample Sensitivity/Clearance ordering are: Top Secret > Secret > Confidential > Unclassified s3 > s2 > s1 > s0 3 33 3 Sample Compartment intersections are: The intersection of {AB} and {A} is {A} The intersection of {c1,c2} and {c1} is {c1} The intersection of {AB} and {C} is {} Formally, for label 1 to dominate label 2 both of the following must be true: The sensitivity/clearance of label 1 must be greater than or equal to the sensitivity/clearance of label 2. The intersection of the compartments of label 1 and label 2 must equal the compartments of label 2. Additionally: Two labels are said to be equal if their sensitivity/clearance and set of compartments are exactly equal. Note that dominance includes equality. One label is said to strictly dominate the other if it dominates the other but is not equal to the other. Two labels are said to be incomparable if each label has at least one compartment that is not included in the other's set of compartments. The dominance relationship will produce a partial ordering over all possible MLS labels, resulting in what is known as the MLS Security Lattice. Information Flows The Multilevel Security policy is concerned with the flow of information from one subject to another. There is a general requirement that information not flow from a "higher" level subject to a "lower" level subject. Flows of information are referred to as channels. For instance, a channel may not exist from a Top Secret user to an Unclassified user as this would allow an Unclassified user access to Top Secret information. Within the Trusted RUBIX DBMS, all SQL operations are controlled to prevent improper information flows. So, for instance, a Confidential user may not SELECT a Top Secret row. Also, a Top Secret user may not UPDATE a Confidential row. A Top Secret user would be permitted to SELECT a Confidential row. In addition to explicit information flow channels, such as selecting a row, Trusted RUBIX also eliminates some covert information flow channels. These are situations where a low level subject can infer information about a "high" level object or subject. Two primary areas where Trusted RUBIX removes illegal covert channels are within the concurrency control algorithm and through the use of polyinstantiation. The following diagram shows the permitted and non-permitted information flows between a representative set of MLS labels. In general, information is allowed to flow from a source to a destination if the destination MLS label dominates (is higher than or equal to) the source MLS label. Note that no information flows are allowed between incomparable MLS labels, such as Top Secret: AB and Top Secret:

C. Also note that not all permitted information flows are shown in the diagram, such as from Unclassified: A to Top Secret: AB. 4 44 4 Figure 2: MLS Information Flows Security Lattice The following diagram shows the MLS Security Lattice for a representative set of MLS labels. The security lattice is a graphical representation of the dominance relationship between all labels in the system. For this example, the system has four sensitivity/clearance labels (TS>S>C>U) and two compartments (A and B). If a path exists from one node to a second node then the label associated with the first node strictly dominates the label associated with the second node. Information is permitted to flow from the first node to the second node. Labels towards the top of the diagram have a higher sensitivity/clearance. Labels towards the right side of the diagram have more categories (need to know). The special label TS:AB is referred to as System High because it dominates all other labels in the system and information may flow to it from any label in the system. The label U is referred to as System Low because it is dominated by all labels in the system and information may flow from it to any other label on the system. Trusted RUBIX uses the same MLS Security policy configuration, and thus security lattice, as the underlying operating system.

Figure 3: MLS Security Lattice 5 55 5

MLS Access Control Rules for SQL Operations 6 66 6 All operations of the Trusted RUBIX DBMS have been integrated with the MLS Security policy, including all SQL operations. All DBMS objects (database, catalog, schema, view, table, index, row) are assigned an MLS label. The rules governing the general behavior of the MLS Security policy are: Newly created objects are assigned the label of the creating subject. A subject may read an object if the subject's label dominates the object's label. A subject may update an object if the subject's label is equal to the object's label. A subject may create a child object within a parent object (e.g., a row within a table or a table within a schema) if the subject's label dominates the parent object. The child will be assigned the label of the creating subject. The following table enumerates the MLS access control rules for each SQL operation. SQL Statement MLS Access Control Rules MLS Outcome ALTER TABLE Session >= parent schema Session = table Table sensitivity label is unchanged. Session = table referenced by a foreign key CONNECT The session sensitivity label for the connecting user is assigned from the label of the operating system connection (e.g., socket label) CREATE CATALOG New object labeled with the session sensitivity label. CREATE DATABASE Any Sensitivity label New object labeled with the session sensitivity label. CREATE INDEX Session >= parent schema New object labeled with the session sensitivity label. Session = table CREATE SCHEMA New object labeled with the session sensitivity label. CREATE TABLE Session >= schema New object labeled with the session sensitivity label. Session = table referenced by a foreign key CREATE VIEW Session >= parent schema New object labeled with the session sensitivity label. Session >= table Session >= view DELETE Session >= parent schema Session >= table, [view] Session = row Delete rows at session sensitivity label. DROP CATALOG Session = catalog Session = any schema, table, or view inside of the catalog Session = any view that references a table and/or view inside of the catalog The catalog and all containing objects (if cascade option specified) are dropped. DROP DATABASE Session = database All objects in the database are destroyed. DROP INDEX Drop the specified index.

7 SQL Statement MLS Access Control Rules MLS Outcome Session >= parent schema DROP SCHEMA DROP TABLE DROP VIEW GRANT INSERT REVOKE SELECT SET CATALOG SET SCHEMA UPDATE sub-query * Session = index Session = schema Session = any table or view inside of the schema Session = any view that references a table and/or view inside of the schema The schema and all containing objects (if cascade option specified) are dropped. The table, all indices, and all rows are dropped. All Session >= parent schema referencing views are dropped (if cascade option Session = table specified). Session = any view referencing the table Session >= parent schema Session = view Session = any view referencing the view Session >= parent object(s) Session = object Session >= parent schema Session >= table, [view] Session >= parent object(s) Session = object Session >= parent schema Session >= table, [view]; Session >= row Session >= catalog Session >= schema Session >= parent schema Session >= table, [view]; Session = row Session >= parent schema Session >= table, [view]; Session >= row The view is dropped. All referencing views are dropped (if cascade option specified). Privileges valid for all sensitivity labels that may access object. New object labeled with the session sensitivity label. Privileges revoked are applicable for all sensitivity labels that may access object. Rows dominated by session sensitivity label are returned. 77 7 Specified catalog name used as default catalog name for all future SQL operations. Specified schema name used as default schema name for all future SQL operations. Rows at the session sensitivity label are updated. Rows dominated by session sensitivity label are returned for the sub-query. * A sub-query is an implied operation on any delete, update, or select operation that includes a where clause and any insert operation that has a select clause. Multilevel DBMS Objects Trusted RUBIX has many DBMS objects that contain child objects. For instance, databases contain catalogs, catalogs contain schemata, schemata contains tables, and tables contain rows. Each of these objects may

8 88 contain child objects that have a sensitivity label that is different than the parent object. The general MLS 8 rule is that a parent object may contain a child object only if that child object's sensitivity label dominates the parent's sensitivity label. Thus, parents objects are able to hold child objects at the same label or higher. MLS multilevel DBMS objects allow container objects to store information from various sensitivity labels while allowing each user to have a view of the database which corresponds to his clearance label, only seeing objects which are dominated by his clearance. All of this happens automatically within Trusted RUBIX. The following diagram demonstrates a database configuration with multiple MLS multilevel DBMS objects. Figure 4: Multilevel DBMS Objects Each user will have a view of the database which corresponds to his clearance label. Objects for which the user is not cleared to access (i.e., those which he does not dominate) will be automatically filtered out of the user's view. Polyinstantiation will insure that naming collisions do not reveal the existence of higher level objects. The following diagram shows the logical view a user would have of the database with an Unclassified, Confidential, and Secret clearance. A Top Secret clearance would have all objects visible and present a view of the database that corresponds to the first diagram.

Figure 5: Views of Multilevel Objects by Clearance 9 99 9 Table SELECT Example The following diagram shows the results of two users, with differing MLS session labels, performing a SELECT operation on the same table. The first user, Bob, is connected to Trusted RUBIX with an MLS session label of Top Secret: A. The second user, Nancy, is connected to Trusted RUBIX with an MLS session label of Confidential: B. Both users are selecting all rows from the MyTab table. In both cases, the SELECT result set will contain only rows which the user dominates. Note that both the user's clearance component must be higher than the row's sensitivity component and the user's compartments must include each of the row's compartments. If a user does not dominate a row, then the row is simply filtered from the result set (no error value is returned). Thus, the existence of the row is hidden. The MLS filtering of the table rows occurs within the DBMS Kernel and below the SQL Engine, making it impossible that an improper row be returned for each SQL operation.

Figure 6: MLS Table SELECT 10 10 10 10 Polyinstantiation The intent of Multilevel Security is to prevent unauthorized information flows to users who are not cleared to access the information. One covert way that illegal information flows may occur within nonsecure systems is by exploiting unique object naming collisions between security domains. The value of a unique key within a row may easily be used to infer the existence of high-level key values by a low-level user not cleared to access the information. Consider the following steps that may be performed within a non-secure DBMS to extract sensitive information. The diagram that follows corresponds to the following steps: 1. A low-level table is created with a unique primary key. 2. A high-level user inserts a value into the low-level table. 3. A low-level user "fishes" for the value of the high-level key by attempting to insert various key values. 4. When the low-level user receives an error message that says the row cannot be inserted because the unique key already exists; and, the low-level users verifies that no such key exists at a dominated level, then the low-level user knows the existence of the high-level key value. This process may be incorporated into a computer program for quick retrieval of high-level information

11 11 resulting in a high bandwidth covert channel. 11 11 Trusted RUBIX removes the potential for such illegal information flows through polyinstantiating DBMS objects that have unique names. This is explained later in this section. Figure 7: Illegal Information Flow of Systems with No Polyinstantiation Trusted RUBIX employs polyinstantiation to eliminate potential illegal information flows that may occur due to naming collision. Polyinstantiation is the process of using duplicate resources or objects to remove conflicts between concurrent accesses. In the case of primary key values, Trusted RUBIX creates a duplicate copy of the row containing the key value when the low-level user attempts an INSERT. Therefore, even though a duplicate key value exists at a high-level, the low-level INSERT succeeds, thereby hiding the existence of the high-level key. When the table is subsequently selected, each user will receives the copy of the row with the highest, dominated label. It is also possible to select all dominated, polyinstantiated rows from a table. The following figure graphically demonstrates polyinstantiation of primary key values.

Figure 8: Removal of the Information Flow with Polyinstantiation 12 12 12 12 Concurrency Control The intent of Multilevel Security is to prevent unauthorized information flows to users who are not cleared to access the information. One covert way that illegal information flows may occur within nonsecure systems is by exploiting locking concurrency control protocols (e.g., two-phase locking or explicitly locking) commonly used within non-secure DBMS products. The illegal information flow is achieved by a high-level user locking a low-level object for read. A lowlevel user then attempts to lock the object for write. Because the write lock requires a unique lock, it will be delayed or denied because of the existence of the high-level lock. The low-level user can then create a program that exploits the existence (or non-existence) of the locking delay to receive information from the cooperating high-level user. The following figure demonstrates this process.

Figure 9: Insecure Concurrency Control Resulting in an Illegal Information Flow 13 13 13 13 Trusted RUBIX eliminates the covert channels provided through locking concurrency protocols by using a unique algorithm know as the Secure Multiversion Timestamp Ordering (Secure MVTO) concurrency control protocol. Secure MVTO creates a new version of a row upon every update and uses transaction timestamps to ensure a user operates on the correct row version. In our example, the high-level user never locks the row being read. Additionally, the low-level user never requires a lock on the row, she simply creates a new version of the row alongside the original version. The following figure demonstrates how Trusted RUBIX and Secure MVTO remove illegal information flows caused by locking concurrency control algorithms.

Figure 10: Trusted RUBIX Secure Concurrency Control 14 14 14 14 MLS OS-DBMS Policy Integration Trusted RUBIX fully integrates the MLS policy of the underlying secure operating system (OS) with that of the DBMS. This results in coherent security behavior across both the OS and DBMS domains. With MLS policy integration, the DBMS session label and the OS session label will be the same for every user. The string label representation and the set of valid label formats will also be the same for Trusted RUBIX and the secure operating system. Additionally, the dominance relationships (i.e., the security lattice) will be the same. Other DBMS products that implement MLS policy enforcement may not integrate with the underlying secure operating system or may be designed to operate on top of a non-mls operating system. In these environments, illegal information flows may occur from the DBMS, to the OS, and then to a user not cleared to access the information. Additionally, the security administrator may have to maintain and configure two MLS policies, each with differing label structures and security lattices. The first of the following two diagrams demonstrates how a malicious user may illegally send information from Top Secret to Unclassified, by exploiting the lack of OS-DBMS policy integration. The second diagram demonstrates how Trusted RUBIX prevents this illegal information flow by integrating with the underlying secure operating system.

15 15 In the first diagram, the malicious user Bob SELECT's Top Secret DBMS data and redirects it to an 15 Unclassified operating system file. Because there is no OS-DBMS policy integration, Bob is able to connect 15 to the DBMS at Top Secret while remaining at Unclassified with respect to the operating system. Nancy then reads the Top Secret DBMS data from the Unclassified operating system file, completing the illegal information flow. Figure 11: Illegal Information Flow in Systems without OS-DBMS Policy Integration The second diagram demonstrates how Trusted RUBIX prevents such illegal information flows by integrating the MLS policies. Because Bob's Trusted RUBIX DBMS and OS session labels are linked, he can only redirect the DBMS data into a Top Secret operating system file. Nancy, being at Unclassified is unable to read from the Top Secret operating system file. Thus, the data remains protected by the same MLS policy in both the Trusted RUBIX DBMS and operating system.

Figure 12: Preventing Illegal Information Flow using OS-DBMS Policy Integration 16 16 16 16 Appendix A: Frequently Asked Questions (FAQ) 1) What was the original posture of NSA toward building a RDBMS MAC/MLS security policy atop a non-secure operating system? It was akin to building a fortress on sand. What was proposed was that security must be built in on a dependable infrastructure on a foundation of solid (e.g., cubic) rocks. 2) What is meant by that statement? This meant that a MAC policy should be implemented in the database kernel and fully integrated with the host Operating System MAC policy and the data always residing in a MLS arbitrated domain. 3) What is the typical MLS architecture? Multiple clients at various levels on networks connecting to a single database and retrieving data based upon the client level.

17 17 4) Specifically, what constitutes a true MLS architecture? 17 17 A TR server running on a Trusted Operating System (TOS) with other machines connected to it via statically labeled networks. TR does not require separate networks with separate servers to enforce different levels of security clearance for cross domain applications. 5) What label does the TR server run at? The TR server runs at the system high label and services clients. This allows the server to access the TOS data files which are isolated at system high. Each TR object is labeled by TR with its object label. The client processes are at whatever level the user is at, either explicitly or implicitly. The TR server detects the client level and sets it at the TR session label. Based upon this session label and object labels, the TR server arbitrates access to TR objects. 6) TR server uses the isolated container model for MLS. Please explain. The TOS provides connection managers by which TR reads the label from the network interface that the TOS controls. This allows non system high processes to query the database and TR ensures that only releasable data is returned to the connection manager. TR maintains all of its database objects in specific isolated (system high/special owner groups and modes) TOS files. This ensures that only TR executables may access the data. Each connection server s process implements MAC and DAC security policies. The MAC policy is stored in the highly assured TR kernel. 7) What is the key component of MLS systems? The key component is MAC which separates sensitive data and access to that data always automatically enforced. 8) How is the TR MAC policy for sensitivity implemented? It is implemented with labels that consist of a hierarchical level and a set of zero or more nonhierarchical categories or compartments. These labels are used to determine access to a resource in accordance with the MAC policy. Since the TR MAC security policy is fully integrated with the TOS MAC policy, there is no special TR configuration needed. 9) How are TR data objects labeled? Every TR data object that is created (database, catalog, schema, table, view, row, and index) is labeled with the current session sensitivity label. This label is set at the TOS TR server process session label. The TR object sensitivity label is maintained within the TR security kernel as a fully autonomous object. 10) What are the dominance rules that apply to comparing TR labels? Two labels are said to be equal if they have the same classification and the same set of compartments. If they are equal, they dominate each other and access is permitted. A label dominates another label if its classification is greater than or equal to that of the other label, and its categories are a super set of the other s categories, access is permitted. If one label has a higher classification or it has the same classifications and its compartments are a superset of the second label s compartments or both, the first label is said to strictly dominate the second label and access is permitted Two labels are said to be disjoint or non-comparable if neither label dominates.

18 18 11) How are TR objects immediately and automatically protected by MAC at creation time? 18 18 For example, when a database is created by executing the CREATE DATABASE command, it is immediately assigned a security label that matches the user s security label. As another example, if the user inserts a row into a table, that row is assigned the security label at which the user is operating. Note that sensitivity labels permit only users at or above the row s sensitivity label to read the row (user s label dominates the label of the row); and only users operating at the object s sensitivity label may modify or destroy the object. 12) How does a user specify a label format in the CREATE TABLE command? There is no syntax needed to specify a label format in the CREATE TABLE command since TR has a label data type that is automatically created as a rowlabel column in a table as hidden field, i.e., the sensitivity label is not automatically displayed unless specifically requested in an SQL query. 13) What is the advantage of fully integrating the labeling and MAC policy of the TOS and TR? TR uses the same binary label and security lattice as the TOS. It relies on the TOS to enforce MAC on its own objects (process, files, etc.), but TR does not rely on the TOS for MAC enforcement of TR objects (database, catalog, schema, table, view, and row). It only relies on the TOS to label network connections, determine a valid label, and determine if one label dominates another. TR stores labels as an intrinsic part of its labeled objects. The labels are stored in the TOS internal format, but can be output in either short or long character strings. Using the TOS means that the label dominance rules, label format (e.g., number of levels, categories, etc.), and any label aliases known to the TOS are available and utilized within TR to determine access. This reduces maintenance and training costs and simplifies application development since only one set of labels is maintained. 14) What about compliance with the Common Criteria Labeled Security Protection Profile (LSPP)? Trusted RUBIX was among the first RDBMS certified to perform fine-grain data access as specified in the LSPP. Applications can be developed that contain multilevel or multi-domain data requests and are content/context filtered for a Community of Interest (COI) through fine grained labels. TR has been certified at EAL 4 (includes label security) on Trusted Solaris 8 by NSA. 15) Trusted RUBIX uses the same MAC security lattice as the underlying TOS. What protection is provided for situations where the movement of protected data from the TOS domain to the TR domain is required? Data moves from the TOS protected domain to the TR protected domain during an INSERT, UPDATE, or rximport command. When the user is NOT operating as the Trusted RUBIX Security Administrator, the database session sensitivity label always equals the TOS session sensitivity label. Trusted RUBIX automatically labels the data with the database session sensitivity label. In this mode there can be no change in the labeling of the data as it changes from the TOS domain to the TR domain. When the user is operating as the TR Security Administrator there is a potential for the data to change its sensitivity label and the user should act accordingly. Using the ALTER SESSION SET

19 19 LABEL command via the rxisql client the TR Security Administrator may change the database 19 session label to one that is greater than, less than, or incomparable to the current TOS session 19 sensitivity label. Therefore, when the data crosses from the TOS domain to the TR domain, the data will implicitly be re-graded from the current TOS session sensitivity label to the current database session sensitivity label. If the TR Security Administrator is using the rximport command in the multilevel mode ( m option), the data will be explicitly labeled to that specified in the text import file. A regular user would need to login to the TOS at each label and perform a single label import. 16) What protection is provided for situations where the movement of protected data from the TR domain to the TOS domain is required? Data moves from the TR protected domain to the TOS protected domain during a SELECT and rxexport operation. When the user is NOT operating as the TR Security Administrator, the database session sensitivity label always equals the TOS session sensitivity label and TR returns only rows that are dominated by the TR session sensitivity label. Once the data enters the TOS domain, the TOS will implicitly label at the TOS session sensitivity label. This may result in an implicit upgrade of data from the current data s TR object sensitivity label to the current TOS session sensitivity label. Using the ALTER SESSION SET LABEL command via the rxisql client, the TR Security Administrator may change the database session label to one that is greater than, less than, or incomparable to the current TOS session sensitivity label. Therefore, when the data crosses from the TR domain to the TOS domain, the data will implicitly be re-graded from the current database session sensitivity label to the current TOS session sensitivity label. 17) In TR DELETE/UPDATE operations what is the TR action if there are no rows at the user s label? If there are dominated rows which satisfy the search criteria then an error is returned. Otherwise, no rows affected is returned. 18) Does TR provide a secure default configuration? Yes. The default TR configuration is secure. There is no need for users to remove features not needed or to verify that user, platform, and application security measures are in place before the database goes into production. 19) How do TR clients make a connection request to a TR server process? A connection request is made to the TR Dispatcher (which runs persistently with a system high session label) by sending a trusted socket message on a publicly known port. The Dispatcher maintains a cache of idle server processes along with their database session sensitivity label. The database session sensitivity label generally remains static during a server process s lifetime (the exception is the trusted operation Alter Session noted in # 15 above). The Dispatcher first maps the client s connection request to an idle server with the same sensitivity label as the client. If such a server process exists, the listening port of the idle server is returned to the client. If no such idle server process exists, the Dispatcher forks a new server process and returns the listening port to the client. In both cases, the server process reads the client s session sensitivity label from the trusted socket s extended security attributes and sets the database server s session to be equal to that of the client session label. Thus, the Dispatcher is not relied upon to tell the servers what database

20 20 session sensitivity label to use. 20 20 Of course, if a trusted user does an Alter Session command, that changes the session label and the object will behave accordingly. The bottom line is that the data is at the label of the process, and the TOS ensures that the process label is the same as the user s session label. TR reads the label from the process and proceeds accordingly. 20) To conform to the MLS security policy what restrictions are there on TR SQL operations? In general, create operations result in labels being applied to new objects, update operations are restricted to objects of the same label as the subject, and reads return only objects which are dominated by the subject. 21) What specific benefit is provided by TR to protect sensitive data flow? Special provisions are made to the metadata to allow selecting the label of such objects. Polyinstantiation is fully supported to remove implicit information flows due to name collisions and to select one or all of such objects.