test

Trusted Solaris Administration Overview

Chapter 3 Administering Trusted Networking

This chapter describes networking in the Trusted Solaris environment. The Trusted Solaris networking subsystem is an exhanced version of the regular Solaris TCP/IP network. The extensions enable communication between workstations on the network in a trusted fashion. The networking subsystem helps ensure that the system's security policy (for example, MAC) is preserved across distributed applications. The amount of administration and protection required for your network depends on whether it is homogeneous or heterogeneous.

Note -

In the default configuration, the security administrator role is responsible for network security.

Overview of Trusted Solaris Networking

This section covers the following networking topics:

Homogeneous Networks

A homogeneous network configuration is the easiest to administer and protect. In a homogeneous network configuration, all workstations run the Trusted Solaris operating environment and use the same NIS or NIS+ master server with the same set of security attributes (clearances, labels, etc.). 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.

Figure 3-1 Homogeneous Network

Graphic

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.

Heterogeneous Networks

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.

Figure 3-2 Heterogeneous Network

Graphic

Trusted Solaris Data Packets

To understand how Trusted Solaris workstations accept data from other Trusted Solaris workstations and hosts using other data protocols, it is useful to compare the standard data packet formats with the Trusted Solaris formats (see figure below).

Figure 3-3 Comparison of Data Packet Formats

Graphic

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 workstations 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.

Security Families

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.

Host Types in Networking

Trusted Solaris classifies host types according to the networking protocols as follows:

Note -

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.

Networking Security Attributes

The security attributes that can be specified in networking templates are:

Networking Templates

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 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 

Network Configuration Databases

There are three network configuration databases for establishing external communication:

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. Trusted Solaris 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 workstations 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 byte(s) 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 Mechanisms 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.

Related Subsystems

The trusted NFS feature of Trusted Solaris 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 Various Types of File Systems in the Trusted Solaris System" in Trusted Solaris Administrator's Procedures.

Routing in Trusted Solaris

In the Trusted Solaris operating environment, routes between hosts on different networks must maintain security at each step in the transmission.

Loading Routing Information at Boot Time

When a Trusted Solaris host boots, it loads routing information so it can transmit data. If the file /etc/tsolgateways (which is maintained manually by the administrator) exists, then the gateways in the file serve as the host's defaults. If, however, /etc/tsolgateways does not exist, then the host uses the default routes from the file /etc/defaultrouter, which is also maintained manually by the administrator. If either file exists, then the host is said to use static routing.

If neither the /etc/tsolgateways nor the /etc/defaultrouter file exists, then the host uses dynamic routing and must start a special daemon, either in.rdisc(1M) (the network router discovery daemon) or in.routed(1M) (the network routing daemon). If the host also serves as a gateway (that is, a host that connects to two or more networks), then both in.rdisc and in.routed are started.

Routing Tables in the Trusted Solaris Environment

The main objective for routing is to find the shortest secure route between two hosts. Trusted Solaris routing tables are based on extended metrics (called emetrics). An emetric is a combination of a routing metric and Security Routing Information (SRI), for measuring security. The SRI can incorporate these security attributes:

This information is propagated by the routing daemon in.routed using the Trusted Solaris-extended Routing Information Protocol if dynamic routing is used, or if static routing is used, by manual entry using the route command or through the /etc/tsolgateways or /etc/defaultrouter files. The emetric for a particular route is used for accreditation checks when this route is being considered.

Not every route in the routing table must have an emetric. If a route does not have an emetric, the remote host template of its first hop gateway is used for the accreditation check instead.

Accreditation Checking

To determine the suitability of a route regarding security, Trusted Solaris runs a series of tests called accreditation checks on the source host, destination host, and the route's emetrics. If the emetric for a particular route is missing, the security attributes for the first-hop gateway in the route are checked. A host's security attributes are derived from information in the tnrhdb, tnrhtp, and tnidb files. The tests check, for example, that a data packet's label is within the range of each host in the route.

Source Accreditation Checks

The accreditation checks conducted on the source host are:

Gateway Accreditation Checks

The accreditation checks conducted on a Trusted Solaris gateway host are:

If the next hop is an unlabeled host, then the label of the source host must match the label of the destination host.

If the packet has the CIPSO option, the following conditions for forwarding must be true:

If the packet has the RIPSO option, the following conditions for forwarding must be true:

Destination Accreditation Checks

When a Trusted Solaris machine receives data, the trusted network software checks for the following:

After the data has passed the accreditation checks above, the system checks that all necessary security attributes are present. If there are missing attributes, the system looks up the source host (by its IP address or a target expression) in the tnrhdb database to get the name of the network security template assigned to the host. The system then retrieves the template's set of security attributes from the tnrhtp database. If there are still security attributes missing, the software looks up the network interface in the tnidb database and retrieves default security attributes.

Routing Example

An example of routing in the Trusted Solaris environment is shown in the following figure; Figure 3-4 (a) shows the routing diagram and Figure 3-4 (b) shows the routing table. There are three potential routes between Host 1 and Host 2:

Figure 3-4 Typical Trusted Solaris Routes and Routing Table

Graphic

Route 

First hop gateway 

RIP Metric 

Min SL 

Max SL 

DOI 

CIPSO 

1 

Gateway 1 

3 

C 

S 

 

 

2 

Gateway 3 

4 

ADMIN_LOW 

ADMIN_HIGH 

 

Y 

3 

Gateway 5 

6 

 

 

 

 

Using Routing Commands

To display the contents of the routing table, use the command netstat with the -R option. To make a manual change to the routing table, use the route command with the add or delete option. For example, 

% route add net 129.150.115.0 129.150.118.39  \
-m metric=2,min_sl=c,max_sl=ts,ripso_label="top_secret sci",\
ripso_error="genser;sci"

add net 129.150.115.0: gateway 129.150.118.39

adds to the routing table a loop with the hosts at 129.150.115.0 and 129.150.118.39 with a distance metric of 2, an SL range from C to TS, a RIPSO label = top_secret sci, and a RIPSO error = genser;sci. To see the results of the added loop, type:

% netstat -Rn
...
129.150.115.0        129.150.118.39        UG       0      0  
        metric=2,min_sl=C,max_sl=TS,ripso_label=0x3d 0x20000000 (top_secret sci)
,ripso_error=0xa0000000 (genser;sci)
...

The new route is shown above. The other routes are replaced by ellipses (...). A second example of adding a route with two new emetrics and viewing the new routing table follows:

% route add net 129.150.114.0 129.150.118.39 \ 
-m metric=3,min_sl=admin_low,max_sl=s,doi=3 \
-m metric=4,min_sl=c,max_sl=admin_high,doi=4,ripso_label="top_secret sci",\
ripso_error="genser;sci"

add net 129.150.114.0: gateway 129.150.118.39
% netstat -Rn
...
129.150.115.0        129.150.118.39        UG       0      0  
        metric=2,min_sl=C,max_sl=TS,ripso_label=0x3d 0x20000000 (top_secret sci)
,ripso_error=0xa0000000 (genser;sci)
129.150.114.0        129.150.118.39        UG       0      0  
        metric=4,min_sl=C,max_sl=ADMIN_HIGH,doi=4,ripso_label=0x3d 0x20000000 (t
op_secret sci),ripso_error=0xa0000000 (genser;sci)
        metric=3,min_sl=ADMIN_LOW,max_sl=S,doi=3
...

Routing through Non-Trusted Solaris Gateway Clusters

It is possible to route secure data through clusters containing non-Trusted Solaris gateways. This procedure is called tunneling. For our purposes, a cluster is a contiguous set of either Trusted Solaris hosts and gateways only, or non-Trusted Solaris hosts and gateways only. An edge gateway is a gateway (Trusted Solaris or non-Trusted Solaris) that connects a cluster to a cluster of the other type.

The following figure shows an example of tunneling. The shaded rectangles represent non-Trusted Solaris gateways. The loops with thick lines indicate clusters. Cluster #1 is a non-Trusted Solaris cluster; cluster #2 is a Trusted Solaris cluster.

Figure 3-5 Tunneling Example

Graphic

To transmit data from host #1 to host #2 requires a route through cluster #1, a non-Trusted Solaris cluster, and cluster #2, a Trusted Solaris cluster. This is permitted under these two conditions only:

Trusted Solaris Network Commands

The following network commands come from the Solaris environment and have been modified to operate in the Trusted Solaris environment (see the Trusted Solaris Summary section of each man page for the differences).

The following network commands are ony available in the Trusted Solaris operating environment.

The tnd and tokmapd commands launch the trusted network daemon and token mapping daemons, respectively. Token mapping is used when your network is communicating with TSIX host types. The tnctl command loads networking information into the kernel caches; the tninfo command lets you check this information. The tnchkdb examines the network configuration databases for problems. The tokmapctl command lets you troubleshoot problems with TSIX token mapping.

Troubleshooting Networks

The Trusted Solaris tools and commands described in this section can help you debug networking problems. For information on the commands, refer to the appropriate man pages. Refer also to Part 3, "Managing Hosts and Networks," in the Trusted Solaris Administrator's Procedures manual. In addition, standard network debugging commands such as snoop(1M), ipcs(1), and netstat(1M) are available in the Trusted Solaris environment.

Overview of Trusted NFS Mounting

Mounting filesystems in the Trusted Solaris environment is similar to mounting in the regular Solaris system. You can enter the standard mounting information in the vfstab file on the client and the sharing information in the dfstab file on the server or you can set up mounting dynamically by using the mount(1M) command.

The major differences for setting up mounts in the Trusted Solaris environment are:

Specifying Security Attributes for Mounting

The vfstab_adjunct file and mount command with -S option let you specify the security attributes for mounts.

The available security attributes are: