This section covers the following networking topics:
A homogeneous network configuration is the easiest to administer and protect. In a homogeneous network configuration, all systems run the Trusted Solaris operating environment and use the same NIS or NIS+ master server with the same set of security attributes (clearances, labels, and so on). A typical homogeneous network, served by a NIS+ master, is shown in the following figure. The hosts in a homogeneous network are said to be in the same security domain.
Workstations are connected to networks by a physical connector called a network interface. Each network interface has an accreditation range, consisting of a maximum label setting the upper boundary and a minimum label for the lower boundary. The accreditation range controls the sensitivity of the information that can be transmitted or received through the interface.
A single computer running the Trusted Solaris operating environment by itself is considered to be a standalone security domain.
Trusted Solaris networks can also accommodate hosts running different network protocols. A heterogeneous configuration requires more administration than a homogeneous arrangement; you must specify how data from hosts with different protocols will be treated with regard to security policy. The following figure shows a typical heterogeneous network and some different protocols with which a Trusted Solaris network can communicate.
To understand how Trusted Solaris systems accept data from other Trusted Solaris systems and hosts using other data protocols, compare the standard data packet formats with the Trusted Solaris formats (see figure below).
In the standard IPv4 format, there is a header with options, followed by a TCP or UDP header and the actual data. The Trusted Solaris version of an IPv4 packet uses the IP options in the header for security attributes and also a SAMP (Security Attribute Modulation Protocol) header identifying the session management protocol and version and security attributes.
The standard IPv6 format contains a header with extensions, followed by a TCP or UDP header and the actual data. The Trusted Solaris IPv6 packet includes a multilevel security option in the header extensions.
When you configure the network configuration databases for your site, you specify all hosts with which hosts on your network can communicate. You set up templates with default security attribute values, categorized by the host types as explained in the following section.
Network administration in the Trusted Solaris environment is based on the concept of security families, that is, treating host machines with common protocols and identical security requirements the same way. For a host to be able to communicate with other hosts on a Trusted Solaris network, you must identify its host type, that is, its networking protocol, and assign it a template of security attributes.
The Trusted Solaris environment classifies host types according to the networking protocols as follows:
Trusted Solaris - Workstations running Trusted Solaris software. It uses binary representation for security attributes in the protocol.
unlabeled - Hosts that do not send or recognize security attributes.
TSIX - Hosts supporting the TSIX (RE) 1.1 (Trusted Systems Information eXchange for Restricted Environments standard). It uses the same format as Trusted Solaris hosts (see Figure 3-3) except that it uses tokens (arbitrary 32-bit numbers) rather than binary data to represent security attributes. The tokens use the security attribute token mapping protocol (SATMP).
CIPSO - Hosts conforming to CIPSO, TSIX (RE) 1.1. The only security attributes supported under CIPSO are the DOI (domain of interpretation) and CIPSO label.
RIPSO - Hosts conforming to RIPSO, as described in the IETF RFC 1108. The Trusted Solaris environment supports an administratively-set fixed RIPSO label to be applied to incoming and outgoing network packets. Although this functionality does not fully meet the RFC specifications, it supplies sufficient functionality where RIPSO labels are needed.
The TSIX, CIPSO, and RIPSO host types lie in the category of hosts running other trusted operating environments. The unlabeled host type is intended for those hosts that use the standard networking protocol and do not support security attributes.
The security attributes that can be specified in networking templates are:
Minimum label - Defines the bottom of the label range for this security family. Outgoing packets to hosts in this security family cannot be below the minimum label.
Maximum label - Defines the top of the label range for this security family. Outgoing packets to hosts in this security family cannot be higher than the maximum label.
Default label - Sets the label to be applied by default to incoming packets from hosts in this security family.
Default clearance - Sets the clearance to be applied by default to incoming packets from hosts in this security family.
DOI - An integer that identifies the domain of interpretation, that is, the labelling scheme used by the default label and clearance for the particular host type.
IP label - Identifies type of IP label: RIPSO, CIPSO, or none. If CIPSO, the /etc/system and label_encodings files must be modified to accommodate the ADMIN_HIGH
label (see the "About Security Families"
help card). If RIPSO, you must specify a RIPSO label for the RIPSO Send Class.
Allowed privileges - Can be used to restrict privileges available to remote Trusted Solaris hosts. If these hosts can use any privileges, set All. If there is a limit, specify only those privileges that can be applied.
Forced privileges - Sets privileges to enable a remote host, typically an unlabeled host, to perform specific functions that may override security policy.
RIPSO Send Class - Used by RIPSO hosts and with RIPSO IP labels only, the classification level at which datagrams sent to a host of that template are protected. The predefined Classes are Top Secret, Secret, Confidential and Classified.
RIPSO Send PAF (protection authority flag) - Used by RIPSO hosts and with RIPSO IP labels only, the bit mask identifying the protection authorities on datagrams sent to a host of that template. The predefined authorities are: GENSER, SIOP-ESIm SCI, NSA, and DOE.
RIPSO Return PAF (protection authority flag) - Used by RIPSO hosts and with RIPSO IP labels only, specifies the PAF portion of the RIPSO label on ICMP error messages sent back from hosts using this template.
The purpose of the Trusted Solaris networking templates is to specify the security attribute values to be applied to hosts within a security family. Not all of the security attributes are appropriate to each host type. The following table indicates how security attributes are applied to which host types. The term default means that the attribute is supplied by default. Optional means that is your choice whether to use this default. Not allowed means that any entry will be ignored. Required with or without conditions means that the attribute is mandatory.
Table 3-1 Security Attributes by Host Type
Host Types --> Security Attributes |
Trusted Solaris |
TSIX |
Unlabeled |
CIPSO |
RIPSO |
---|---|---|---|---|---|
minimum label |
default |
default |
default |
default |
default |
maximum label |
default |
default |
default |
default |
default |
default label |
not allowed |
not allowed |
default |
not allowed |
default |
default clearance |
not allowed |
not allowed |
default |
default |
default |
DOI |
optional |
optional |
optional |
optional |
optional |
IP label |
optional |
optional |
optional |
optional |
optional |
forced privileges |
not allowed |
not allowed |
default |
default |
default |
allowed privileges |
default |
default |
not allowed |
not allowed |
not allowed |
RIPSO Send Class |
required if host or IP label is RIPSO |
not allowed |
required if host or IP label is RIPSO |
not allowed |
required |
RIPSO Send PAF |
required if host or IP label is RIPSO |
not allowed |
required if host or IP label is RIPSO |
not allowed |
required |
RIPSO Return PAF |
required if host or IP label is RIPSO |
not allowed |
required if host or IP label is RIPSO |
not allowed |
required |
There are three network configuration databases for establishing external communication:
tnrhdb
tnrhtp
tnidb
These databases are loaded into the kernel and are used in accreditation checks as data is transmitted from one host to another. These databases are maintained using the Computers and Security Families dialog boxes in the SMC Computers and Networks tool and the SMC Interface Manager. The Trusted Solaris environment can use a naming service for central management of the tnrhdb and tnrhtp databases. The tnidb database is maintained separately on each host.
Network host information is stored in the tnrhdb(4) database. It holds the IP addresses for all hosts permitted to communicate with hosts in the network and the templates, from the tnrhtp database, assigned to them. The tnrhdb database can also hold default values as part of a fallback mechanism. Substituting 0 in the rightmost bytes of the IP address serves as a wildcard for unlisted hosts with IP addresses that match the non-zero portion of the default. You can also set a fixed prefix length by adding a slash (/) followed by the number of fixed bits. See the following table for examples.
Table 3-2 tnrhdb Fallback Mechanism Example
tnrhdb Entry |
Addresses Covered |
---|---|
129.150.118.0:tsol |
Addresses beginning with 129.150.118. |
129.150.0.0:tsol |
Addresses beginning with 129.150. |
129.0.0.0:tsol |
Addresses beginning with 129. |
0.0.0.0:tsol |
All addresses on network |
129.150.118.128/26:tsol |
Addresses from 129.150.118.0 to 129.150.118.63 |
Network template information is stored in the tnrhtp(4) database. In a homogeneous network, only one template is needed. In a heterogeneous network, you need a separate template for each type of host. The attributes in the templates provide attributes from incoming data. They also provide destination information for outgoing data and are use in accreditation checks for incoming packets.
The tnidb(4) database is local to each host. It contains the host's network interfaces with their accreditation ranges. Default values for labels, clearances, effective UIDs/GIDs, and forced privileges apply to communications to and from hosts running environments that do not support these attributes. Note that any default values set in tnrhtp override the values in tnidb. By default, the file is empty because default values are used for all interfaces.
The trusted NFS feature of the Trusted Solaris environment permits mounting between Trusted Solaris hosts and the other host types. Transmitted data is protected by MAC and DAC. Missing labels are supplied by the tnrhtp and tnidb databases. For more information, see "Mounting File Systems in the Trusted Solaris Environment" in Trusted Solaris Administrator's Procedures.