Server Virtualization Using Trusted Solaris 8 Operating Environment
- Using Labels for Containment
- Labeled Processes
- Service Provider Network Configuration
- Customer Web Site Configuration
- Resource Constraints
- Summary
- Acknowlegements
This article builds on the concepts presented in our previous Sun BluePrints™ OnLine article, Maintaining Network Separation With Trusted Solaris™ 8 Operating Environment1, which provided an introduction to the configuration of labeled networks. In this article, we expand on those techniques to show how the Trusted Solaris™ Operating Environment (OE) can be deployed by a network service provider to support multiple customers within a single infrastructure.
Through the use of appropriate Trusted Solaris software functionality, each customer appears to have its own virtual server, or community. This article describes some of the administrative procedures and configuration files that are required to set up fully contained communities. The configuration depends on some new functionality provided in the 4/01 update.
Using Labels for Containment
Containment is a critical requirement when hosting multiple clients in the same infrastructure. It must not be possible for the clients to interfere with each other or have any access to other's data. The mechanisms employed to implement this containment must provide high assurance and strength of protection. Trusted Solaris OE has been certified to meet the ITSEC F-B1 functionality requirements with an assurance level of E3. The current release of Trusted Solaris OE is also being evaluated using the Common Criteria protection profiles for Labeled Security(B1) and Role-Based Access Control, with an assurance level of EAL-4. The evaluation criteria are described in the Common Criteria Web site2.
Labels are used to enforce a policy known as Mandatory Access Control (MAC). The policy is called mandatory because it is automatic and cannot be changed by normal users. This is in contrast to the Discretionary Access Control (DAC) provided in standard operating environments, where the owner of data is responsible for access control. Labels are applied pervasively and automatically to all data objects and all information flows, including networking, file systems, windowing, and interprocess communication. Although many people tend to think of traditional labels like Top Secret, or Unclassified, labeling can be quite natural and straight-forward. In fact, in the network security provider environment, only the security administrator needs to know the names of the labels and their relationships.
Associating Labels with Customers
Label names and relationships are defined in a database known as /etc/security/tsol/label_encodings. Although the administrative tools deal with labels as textual elements, they are internally maintained in a binary representation. Labels consist of two components, a hierarchical classification and a non-hierarchical array of bits known as compartments.
In this article, we refer to a Service Provider database which is available for download from the Sun BluePrints Web site (http://sun.com/blueprints/tools/tsolsp-scripts_license.html). It provides for 100 independent client communities, arbitrarily named Customer1 to Customer100. The actual number of communities could be much larger. Although these names can easily be replaced with those of actual customers, it isn't required because the labels are not displayed by default. However, the installation of the label_encodings file is a prerequisite for most of the other steps described in this article; it is typically installed from a floppy disk after a CD-ROM installation of Trusted Solaris OE, or via Jumpstart™ software for a network installation.
In addition to the Customer labels, the database also includes the Public and Private labels that were discussed in the previous Sun BluePrints article. Finally, there are two special administrative labels which are implicitly included in every labels database. The following table summarizes the label names and functions.
TABLE 1 Summary of Service Provider Labels
Public Internet |
This label is the minimum label which can be assigned to users |
Private Intranet |
This label can be assigned to normal users within a corporate network. |
Customer1 (C1) |
This label is used to isolate Customer1's data from the other customers. It has two compartments:
|
Customer2 (C2) |
This label is used to isolate Customer2's data from the other customers. It has the same two compartments as Customer1:
|
Service Provider (SP) |
This label is used as a maximum for all of the user labels. |
Admin_Low |
This is the lowest administrative label. Information at this label is read-only, except by authorized administrators. Users cannot execute processes at this label, so they cannot write to files or directories at this label. |
Admin_High |
This label is the highest administrative label. Information at this label may only be read by authorized users. It protects the audit trail and the labels database. |
In the simplest case, a label dominates another if its classification is greater than or equal to the other and it contains all of the compartment bits of the other label. However, the relationship between labels can be disjoint when each label has at least one compartment bit not present in the other. Since there is no dominance relationship between disjoint labels, they are completely isolated from each other.
In the sample label database, the Private label and the Customer labels are all disjoint, but they all dominate the Public label and the Admin_Low label. The Service Provider label dominates everything except the Admin_High label, and can be used as a maximum when a network or a user is cleared to multiple levels. The complete dominance relationship is shown in FIGURE 1.
FIGURE 1 Label Dominance Relationships
Note that for each customer there are two disjoint labels, one for the web server and one for the CGI scripts. Each of these labels dominates the minimum customer label which is used to protect the customer's data.
These relationships are important because they provide the necessary containment. Each process runs with one of the labels shown in FIGURE 1. The label of the process prevents it from sending or receiving any information which would violate the MAC policy. For example, a process can only read a file if its label dominates that of the file, and can only write a file at its own label. The system is designed so that the policy is usually transparent and does not interfere with normal activity.