Trusted
RUBIX
TM
Version
6
R
ELATIONAL
D
ATABASE
M
ANAGEMENT
S
YSTEM
Infosystems Technology, Inc. 4 Professional Dr - Suite 118
Gaithersburg, MD 20879
TEL
+1-202-412-0152Multilevel Security in Trusted
RUBIX
White Paper
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.
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
11 1
Overview
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 security-wise 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.
22 2
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.
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.
33 3
Sample Sensitivity/Clearance ordering are:
Top Secret > Secret > Confidential > Unclassified s3 > s2 > s1 > s0
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 label1 to dominate label2 both of the following must be true:
The sensitivity/clearance of label1 must be greater than or equal to the sensitivity/clearance of
label2.
The intersection of the compartments of label1 and label2 must equal the compartments of label2.
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:
44 4
C. Also note that not all permitted information flows are shown in the diagram, such as from Unclassified: A to Top Secret: AB.
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.
55 5
66 6
MLS Access Control Rules for
SQL
Operations
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 >= database Session >= parent catalog Session >= parent schema Session = table
Session = table referenced by a foreign key
Table sensitivity label is unchanged.
CONNECT Session >= database
The session sensitivity label for the connecting user is assigned from the label of the operating system connection (e.g., socket label)
CREATE CATALOG Session >= database New object labeled with the session sensitivity label.
CREATE DATABASE Any Sensitivity label New object labeled with the session sensitivity label.
CREATE INDEX
Session >= database Session >= parent catalog Session >= parent schema Session = table
New object labeled with the session sensitivity label.
CREATE SCHEMA Session >= database
Session >= parent catalog New object labeled with the session sensitivity label.
CREATE TABLE
Session >= database Session >= parent catalog Session >= schema
Session = table referenced by a foreign key
New object labeled with the session sensitivity label.
CREATE VIEW
Session >= database Session >= parent catalog Session >= parent schema Session >= table
Session >= view
New object labeled with the session sensitivity label.
DELETE
Session >= database Session >= parent catalog Session >= parent schema Session >= table, [view] Session = row
Delete rows at session sensitivity label.
DROP CATALOG
Session >= database 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.
77 7
SQL Statement MLS Access Control Rules MLS Outcome
Session >= parent catalog Session >= parent schema Session = index
DROP SCHEMA
Session >= database Session >= parent catalog 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.
DROP TABLE
Session >= database Session >= parent catalog Session >= parent schema Session = table
Session = any view referencing the table
The table, all indices, and all rows are dropped. All referencing views are dropped (if cascade option specified).
DROP VIEW
Session >= database Session >= parent catalog Session >= parent schema Session = view
Session = any view referencing the view
The view is dropped. All referencing views are dropped (if cascade option specified).
GRANT Session >= parent object(s)
Session = object
Privileges valid for all sensitivity labels that may access object.
INSERT
Session >= database Session >= parent catalog Session >= parent schema Session >= table, [view]
New object labeled with the session sensitivity label.
REVOKE Session >= parent object(s)
Session = object
Privileges revoked are applicable for all sensitivity labels that may access object.
SELECT
Session >= database Session >= parent catalog Session >= parent schema Session >= table, [view]; Session >= row
Rows dominated by session sensitivity label are returned.
SET CATALOG Session >= database
Session >= catalog
Specified catalog name used as default catalog name for all future SQL operations.
SET SCHEMA
Session >= database Session >= parent catalog Session >= schema
Specified schema name used as default schema name for all future SQL operations.
UPDATE
Session >= database Session >= parent catalog Session >= parent schema Session >= table, [view]; Session = row
Rows at the session sensitivity label are updated.
sub-query*
Session >= database Session >= parent catalog Session >= parent schema Session >= table, [view]; Session >= row
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
88 8
contain child objects that have a sensitivity label that is different than the parent object. The general MLS
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.
99 9
Figure 5: Views of Multilevel Objects by Clearance
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.
10 10 10
Figure 6: MLS Table SELECT
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 non-secure 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.
11 11 11
resulting in a high bandwidth covert channel.
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.
12 12 12
Figure 8: Removal of the Information Flow with Polyinstantiation
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 non-secure 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 level object for read. A low-level 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.
13 13 13
Figure 9: Insecure Concurrency Control Resulting in an Illegal Information Flow
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.
14 14 14
Figure 10: Trusted RUBIX Secure Concurrency Control
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 15
In the first diagram, the malicious user Bob SELECT's Top Secret DBMS data and redirects it to an
Unclassified operating system file. Because there is no OS-DBMS policy integration, Bob is able to connect 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
16 16 16
Figure 12: Preventing Illegal Information Flow using OS-DBMS Policy Integration
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 17
4) Specifically, what constitutes a true MLS architecture?
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 non-hierarchical 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 18
11) How are TR objects immediately and automatically protected by MAC at creation time?
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 19
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 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 20
session sensitivity label to use.
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.
