Security attributes are administratively assigned to computers (hosts and routers) by means of templates. The Security Administrator role administers templates and assigns templates to computers using the Security Families tool. If a computer does not have a template assigned, no communications are allowed with that computer. Computers that share the same template are considered to be part of the same security family.
Every template has a Host Type, which determines which protocol is used to communicate with the computer that is assigned the template. The protocols tell the kernel which security attributes to look for in the header of an incoming packet or to insert into an outgoing packet. See "Host Types".
Every template also has an Accreditation Range (consisting of a Minimum Label and a Maximum Label) and a default DOI (Domain of Interpretation). For details about these attributes, see "Computer Accreditation Range" and "Domain of Interpretation (DOI)".
Each host type has its own set of additional required and optional security attributes, which are introduced in the following list:
Templates for the Unlabeled and RIPSO host types specify a Default Label that is used to control communications with computers whose operating environment is not aware of labels, such as Solaris or RIPSO-cognizant operating environments.
Because communications with these computers are essentially limited to the Default Label, they are referred to as single-label computers. See "Default Label".
Templates for single-label computers also specify a Default Clearance. One or more optional privileges can be specified in the template's Forced Privileges field. See "Default Clearance" and "Forced Privileges".
The template for the Trusted Solaris host type has an Allowed Privileges field that can optionally be used to limit the privileges accepted from the remote computer. See "Allowed Privileges".
The template for any host type can be used to specify an IP label to be used in trusted routing of packets. See "Using IP Labels in Trusted Routing".
For more about specifying an IP label or how to change the default DOI, see "Advanced Security Attributes".
The following table describes the host types for which entries can be made in the trusted network databases. The first column shows the name used in the Security Families host type menu.
Table 7-1 Host Types, Protocols, and Notes
Name in Template Manager |
Protocols and Notes |
---|---|
Trusted Solaris |
The TSOL protocol simplifies passing security attributes between computers running Trusted Solaris 2.5.1, Trusted Solaris 7, Trusted Solaris 8, or Trusted Solaris 8 4/01 releases. TSOL is a derivative of the TSIX(RE) 1.1 - SAMP protocol that passes the security attributes in a similar place in the network protocol stack and uses similar header structures. The TSOL protocol passes security attributes in binary form and thus does not require token mapping. NOTE: For communications between Trusted Solaris computers, either the Trusted Solaris or TSIX host type can be assigned in the templates, depending on whether you want the labels to be transmitted in binary form or in token form. If only the labels' names differ on two computers while the labels' binary representations are the same, the Trusted Solaris host type can be used. If the labels' names are the same but the labels' binary representations are different on both Trusted Solaris computers, the TSIX host type can be assigned. |
Unlabeled |
This host type is assigned to computers running Solaris or other unlabeled operating environments to specify a default label and default clearance to apply to communications with the unlabeled computer. Also, a minimum and maximum label can be set to allow the sending of packets to an unlabeled gateway for forwarding when the packets' labels do not match the default label and would therefore not be sent to the computer as a destination. |
RIPSO |
Revised IP Security Option (RIPSO) described in the IETF RFC 1108. It specifies a DoD IP labeling method to incorporate labels into IP packets, which are then used for network mandatory access control checks. A fixed RIPSO label specified in the template is applied to network packets interchanged with the particular host. Though this functionality does not fully meet the RFC specifications, it is expected to supply sufficient functionality where RIPSO labels are needed. |
CIPSO |
Common IP Security Option (CIPSO) protocol TSIX(RE) 1.1 is used to specify security labels that are passed in the IP options field. CIPSO labels are derived automatically from the data's label. Tag type 1 is used to pass the CIPSO security label. This label is then used to make security checks at the IP level and to label the data in the network packet. |
TSIX |
Trusted Security Information Exchange for Restricted Environments (TSIX/RE) protocol uses token mapping to pass security attributes. Can be used for computers running the Trusted Solaris or other TSIX-cognizant operating environments. See the NOTE for the Trusted Solaris host type in the first entry in this table. |
The Minimum Label and the Maximum Label are used in the following ways:
To set the range of labels that can be used when communicating with a computer.
In order for a packet to be sent to a computer, the label of the packet must be within the label range assigned to the destination computer in its template.
To set a label range for packets being forwarded through an unlabeled or RIPSO gateway.
The label range can be specified in the template for an unlabeled or RIPSO host type to make it possible to forward a packet to that computer for forwarding, even when the packet's label is not the same as the Default Label.
A default Domain of Interpretation is assigned in the default templates for all host types. Two computers need to have the same DOI in order to communicate. Organizations with the same DOI need to agree among themselves about how labels and other security attributes are to be interpreted. Each host type has a DOI associated with it. By default each existing or new template has the default DOI specified in the DOI field. You do need to change the default DOI unless you have reasons for wanting to do so.
As mentioned under "Host Types", either the Trusted Solaris or TSIX host type can be specified in templates assigned to Trusted Solaris computers. If the NOTE in the first entry in Table 7-1 is true for your site, the Trusted Solaris or TSIX host-type computers can share the same DOI .
In Trusted Solaris IPv4 packets, the DOI is carried in the packet along with the label. In an IPv4 packet, the specified DOI is included both with the IP options (if any are specified) and in the SAMP header.
Headers ( Options [IP options including DOI] ) |
SAMP including DOI |
Data |
Trusted routing using IP labels is not supported with IPv6.
In Trusted Solaris IPv6 packets, label information is carried in multilevel security (MLS) options portion of the packet's Headers. Because label information is in the Headers portion of the packet, the packet's label can be used for routing.
Headers ( Options [SAMP MLS options including DOI] |
Data |
To specify a DOI other than the default, use the Advanced Security Attributes tabs.
Each unlabeled or RIPSO-type computer is assigned a single label in the Default Label field. The Default Label assigned to an unlabeled or RIPSO-type computer should reflect the level of trust that is appropriate for the computer and its users. For RIPSO hosts, the Default Label should be the same as the RIPSO Label (which is a combination the RIPSO Send Class and the RIPSO Send PAF).
Each single-label computer (with the Unlabeled or RIPSO host type) is assigned a clearance in the Default Clearance field. The clearance sets the upper limit for write operations performed on the Trusted Solaris computer by someone on the unlabeled host. For example, on an unlabeled computer with a Default Label of CONFIDENTIAL and Default Clearance of SECRET, a user who is working on a file system mounted from a Trusted Solaris host can open an upgraded file with a label of SECRET and write into it (if the file's name is known to that user).
One or more privileges can be specified in the Forced Privileges field of a template that has the unlabeled host type. An unlabeled computer does not recognize privileges. Specifying privileges in this field affects only how the Trusted Solaris computer handles requests from a program that is running on the unlabeled computer. Privileges can be specified to allow a client from an unlabeled computer to do something not otherwise permitted, such as reading a file whose label dominates that of the client or communicating with X clients owned by another user.
Remote Trusted Solaris computers can usually be trusted to provide correct privileges. If needed, the privileges that a remote Trusted Solaris computer is allowed to use can be controlled by specifying a restricted set of privileges in the Allowed Privileges field of a template with the Trusted Solaris host type. Processes running on a remote Trusted Solaris system communicate their effective privileges as part of their security attributes. You can locally restrict those privileges to the ones that are specified in the Allowed Privileges set.
The Advanced Security Attributes tab in the Security Families Template dialog box sets the following options.
DOI
Every type of supported protocol has a domain of interpretation field. The DOI identifies the labeling scheme. Computers need to have the same DOI in order to communicate. Two organizations that use the same DOI need to agree among themselves to interpret label information the same way.
You need to replace the default domain of interpretation (DOI) only if your site needs another number than the default that is assigned to each host type. Replace the DOI, if desired, by entering an integer into the DOI field.
The type of DOI (TSOL, TSIX, or CIPSO) is determined from the type of host and from any IP label specified in a machine's template. For example, on a Trusted Solaris router with an IP label of CIPSO, the DOI is understood to be a CIPSO DOI.
IP Options
If using trusted routing with IPv4 packets, choose either "none," "CIPSO," or "RIPSO" from the IP Label pull-down menu.
When the CIPSO IP label is specified in a host's template, then a CIPSO label is inserted into the IP options portion of any packet outgoing to that host. See "CIPSO Labels in Packets" for how CIPSO labels are used.
If you choose RIPSO, you need to choose a RIPSO Send Class, an optional RIPSO Send PAF, and RIPSO Return PAF from the pull-down menus. PAF means Protection Authority Flag. Any Send PAF specified is used like a compartment name along with the classification to make up the RIPSO label (as in Top_Secret SCI). The PAF specified in the Return PAF is used in labeling ICMP messages that can be generated as errors in response to incoming RIPSO labeled packets . The Send Class is also sent back with the RIPSO error in an ICMP message. The RIPSO label should have the same name as the Default Label assigned to the host. Make sure to specify the same RIPSO label and RIPSO PAFs for the sending host, all gateways, and the destination host. See "RIPSO Labels in Packets" for how RIPSO labels are used.