test

Trusted Solaris Administrator's Procedures

Default Templates

Trusted Solaris software ships with a set of templates that matches the label_encodings(4) file on the installation disk. Icons for all defined templates appear when the Security Families tool is double-clicked. The Security Families tool enforces the required fields in the templates, based on the host type.

Caution - Caution -

If your site has installed its own label encodings, you must modify the templates to work with your labels.

The simplest and safest configuration is to enable communication only among Trusted Solaris computers that share the same label_encodings file. To set up such a configuration, the System Administrator role can assign the default TSOL template or other similar template with the Trusted Solaris host type to all Trusted Solaris computers.

Default Templates for Trusted Solaris Systems

A computer running Trusted Solaris 2.5.1 and later compatible releases can be assigned any template that has the Trusted Solaris host type. See the online help in the Security Families tool for a description of the default templates for the Trusted Solaris host type.

Default Templates for Unlabeled or RIPSO Computers

The Trusted Solaris environment supports communications with computers running operating environments that do not recognize labels (such as the Solaris operating environment). A computer that does not recognize labels or that uses RIPSO labels must be assigned a single label and a clearance. The label and clearance restrict communications with that computer. Before assigning a template that has the Unlabeled or RIPSO host type to an unlabeled host, specify the following:

Caution - Caution -

When creating or modifying a template for an unlabeled or RIPSO-type computer, do not forget to change the default label to reflect the level of trust it should be accorded. Administrators who report problems with not being able to communicate with remote single-label computers at the expected label have usually forgotten to specify that label in the Default Label field.

The default unlabeled and ripso host type templates are valid only when either the default label_encodings file is used or another label encodings file with the same label names and binary representations for the labels. See the online help in the Security Families tool for descriptions of the default unlabeled or RIPSO templates.

Do not use the admin_low template during normal system operations. The admin_low template is needed during initial boot only, before the system is configured. The template assignment is stored in the tnrhtp and tnrhdb databases in /etc/security/tsol on the installed machine. Once the system is configured, the Security Administrator role should either remove the 0.0.0.0 entry entirely or change it to assign a template with an appropriate hots type and security attributes.

Wildcard Entry and Prefix Length

A wildcard IP address is the IP address of a subnetwork. A subnetwork is defined by its IP address and its netmask. The netmask determines the prefix that has to be common to all the addresses belonging to a subnetwork.

For example, the IP address 192.168.123.0 is a wildcard with a netmask = 255.255.255.0. The subnet is made up of all the IP addresses between 192.168.123.1 and 192.168.123.255. A optional Prefix Length can be specified in the form of an integer. The prefix length determines the size of the subnet and is the number of 1 bits in the netmask.

Table 7-2 Wildcard Address, Netmask, and Prefix Length

class A addresses: a.0.0.0, or a 

class B addresses: a.b.0.0, or a.b  

class C addresses: a.b.c.0, or a.b.c  

netmask = 255.0.0.0 

netmask = 255.255.0.0 

netmask = 255.255.255.0 

prefix length = 8  

prefix length = 16  

prefix length = 24 

With variable-length subnetting, the prefix length does not have to be a multiple of 8. For example, you can have the IP address 192.168.123.224, with a netmask = 255.255.255.224, and a prefix length = 27, covering the addresses between 192.168.123.225 and 192.168.123.255. IPv4 network addresses can have a prefix length between 1 and 32. IPv6 network addresses can have a prefix length between 1 and 128.

The trusted network software looks first for an entry that specifically assigns the host to a template, and if it does not find a specific entry, the software looks for the subnetwork entry that best matches the hosts's IP address (a subnetwork with the longest prefix length to which that address belongs).

If a computer's IP address cannot be matched to an entry, communication with that computer is not permitted.

A default 0.0.0.0 entry matches all computers that are not otherwise matched by other entries.

Sites that need to strictly control remote access should remove the 0.0.0.0 entry. They should also assess whether to use any wildcard addresses. For more information, see the tnrhdb(4) man page.)

CIPSO Labels in Packets

The CIPSO label is derived from the actual label of the data on the sending Trusted Solaris computer.

The trusted networking software puts a CIPSO label and a DOI (domain of interpretation) number into the IP option for outgoing packets and also looks for a CIPSO label and DOI in the IP option of incoming packets, if the trusted network template entry assigned to the remote host meets one of these criteria:

The CIPSO label that is inserted into outgoing packets is derived by the trusted networking software from the actual label associated with the data. Sometimes Trusted Solaris labels match directly to a CIPSO label. For example, the label of CONFIDENTIAL matches the CIPSO label of CONFIDENTIAL. However, most Trusted Solaris labels do not map directly to CIPSO labels.

Note -

At a site that plans to use CIPSO labels for trusted routing or wishes to communicate with a host with a host type of CIPSO, the Security Administrator role should plan ahead to configure the site's labels so they map well to CIPSO labels.

A DOI (domain of interpretation) must also be specified, and the same DOI must be:

Ensuring Labels Are Mappable to CIPSO Labels

The Security Administrator role needs to plan ahead to ensure that the labels defined in the label_encodings(4) file map well to CIPSO labels. See Trusted Solaris Label Administration.

RIPSO Labels in Packets

The RIPSO, Revised IP Security Option, protocol is described in the IETF RFC 1108. The trusted networking software puts a RIPSO label into the IP option for outgoing packets and also looks for a RIPSO label in the IP option of incoming packets from a host, if the trusted network template entry for the host meets one of these criteria:

RIPSO labels on outgoing packets are administratively defined. The Security Administrator role specifies them in the tnrhtp database, putting the classification in the RIPSO Send Class field and the compartment(s), or protection authority flags (PAF) in the RIPSO Send PAF field.

The following RIPSO Send classifications are supported: Top_Secret, Secret, Confidential, and Unclassified.

The RIPSO Send PAF and Return PAF fields refer to Protection Authority Flags, which are shown in the following table. PAFs specified in the Send PAF field are used like compartment names along with the classification within the RIPSO labels (as in Top_Secret SCI). PAFs specified in the Return PAF field are used in labeling ICMP messages that can be generated as errors in response to incoming RIPSO labeled packets. The classification sent back in an ICMP message is the same as the RIPSO classification in the packet.

Table 7-3 Protection Authority Flags
 Protection Authority Flags (may be specified along with supported classifications in RIPSO labels or specified as RIPSO errors)
GENSER
SIOP-ESI
SCI
NSA
DOE