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.
In the default configuration, the security administrator role is responsible for network security.
This section covers the following networking topics:
Homogeneous networks
Heterogeneous networks
Host types
Network configuration databases
Related subsystems
How data is transmitted
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.
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 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).
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.
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.
Trusted Solaris classifies host types according to the networking protocols as follows:
Trusted Solaris--refers to workstations running Trusted Solaris. It uses binary representation for security attributes in the protocol.
unlabeled--refers to hosts that do not send or recognize security attributes.
TSIX--refers to 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--refers to 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--refers to 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 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. 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.
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.
In the Trusted Solaris operating environment, routes between hosts on different networks must maintain security at each step in the transmission.
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.
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:
Minimum SL
Maximum SL
DOI
RIPSO label
RIPSO error
CIPSO only
RIPSO only
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.
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.
The accreditation checks conducted on the source host are:
The label of the data being sent must be within the destination host's accreditation range.
The label of the data must be within the accreditation range of the emetric for the route or, if the emetric is not available, first-hop gateway's security attributes.
The label of the data must be within the accreditation range of the source host's network interface.
The DOI of an outgoing packet must match the DOI of the destination and the route's emetric (or first-hop gateway).
An outgoing packet's RIPSO label must match the RIPSO label of the destination and the route's emetric (or first-hop gateway). Alternatively, the RIPSO error can match the destination's RIPSO error, the route's emetric, or the first-hop gateway's RIPSO error.
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:
The route's emetric (or next-hop gateway) must be able to accept data in the CIPSO protocol.
The route's emetric (or next-hop gateway) must be in the data packet's DOI.
The DOI (from the tnrhtp database) for the outgoing interface must be the same as the data packet's DOI.
If the packet has the RIPSO option, the following conditions for forwarding must be true:
The route's emetric (or next-hop gateway) must be able to accept data in the RIPSO protocol.
The route's emetric (or next-hop gateway) must have the same RIPSO label (or RIPSO error) as the data packet's RIPSO label (or RIPSO error).
When a Trusted Solaris machine receives data, the trusted network software checks for the following:
The label of the data is within the accreditation range of both the source machine and the network interface receiving the data.
If a packet has a CIPSO label, then the DOI in the packet must be the same as the DOI in the remote host template for the destination.
If a packet has a RIPSO label (or RIPSO error), then the RIPSO label (or RIPSO error) in the packet must be the same as the RIPSO label (or RIPSO error) in the remote host template for the destination.
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.
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:
Route #1 is the shortest with a Routing Information Protocol (RIP) metric of 3. Datagrams using route #1 are restricted to a label range of CONFIDENTIAL (C) to SECRET (S).
Route #2 has a larger label range of ADMIN_LOW to ADMIN_HIGH. Datagrams using route #2 must use have an IP Option set to CIPSO.
Route #3 has the longest distance of the three routes with an RIP of 6. Its Security Routing Information is unknown, so any security attributes must be derived from the template in tnrhtp for Gateway #5.
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 |
|
|
|
|
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 ...
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.
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:
All the gateways in the non-Trusted Solaris cluster (in the example, gateways #1, #2, and #3) must have the same security attributes. At start-up, each gateway must have a local file called /etc/security/tsol/tunnel containing the addresses of target hosts with which it can connect.
If there is more than one possible route and the routes enter the non-Trusted Solaris cluster through the same edge gateway and can exit from the cluster through different edge gateways, then the emetrics for these routes must be the same. For example, assume that gateway #4 has an SL range of CONFIDENTIAL to SECRET and gateway #5 has a broader range of ADMIN_LOW to ADMIN_HIGH. Because gateway #1 is a non-Trusted Solaris host, it uses a standard routing table without security attributes and would be unable to distinguish between the route through gateway #4 and the route through gateway #5.
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.
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.
To get security information for the source, destination, and gateway hosts in the transmission, use tninfo(1M). You can check whether the information that the kernel is caching is correct. This command is intended to be run at ADMIN_HIGH and effective user ID 0. These restrictions can be overridden by the file_mac_read, sys_trans_label, and file_dac_read privileges. Use tninfo as follows:
tninfo -h [<hostname>] displays the IP Address, port, and template for all hosts or the given host.
tninfo -t <templatename> displays the following information for all templates or the given template: host type, minimum label (in label and hex format), maximum label (in label and hex format), allowed privileges, and IP label type (RIPSO, CIPSO, or none).
tninfo -k displays kernel statistics: number of host accreditation check failures, number of network accreditation check failures, and memory allocation statistics.
To change or check network security information, use the SMC tools to access the tnrhtp, tnrhdb, and tnidb files. If you are not using the NIS+ tables for networking, these changes will take place immediately after you exit from SMC. If you are using NIS+ tables, then the changes will take place when the network daemon next polls the databases or when the system is rebooted. If you wish the change to take place sooner, you can shorten the polling interval using tnctl(1M) with the -p option on the host that needs the updated information.
To collect debugging information from the network daemon if the network is already running, use tnctl(1M) with the -d option. Debugging data is written by default to the file /var/tsol/tndlog. Search the log file for failures and other symptoms of problems.
To check TSIX transmissions, use tokmapd with the -d option (or tokmapctl -d) to create a log and choose an appropriate debugging level. Debugging data is written by default to the file /var/tsol/tokmapdlog. Use snoop(1M) to check that both source and destination can transmit tokens.
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:
The vfstab(4) file is supplemented by a special file called vfstab_adjunct(4), whose purpose is to hold security attributes to be applied to the file system.
The server needs to have a template assigned in its tnrhdb file that it can apply to the client. If you are setting up a mount between two Trusted Solaris hosts, use a template for Trusted Solaris hosts. If you are setting up a mount between a Trusted Solaris host and an unlabeled host, all data is transmitted by default at the single label specified for the unlabeled host in the tnrhdb file; however, you can specify different non-label security attributes at mount time using the vfstab_adjunct(4) file or the mount(1M) command with the -S or -o option.
The physical connection between the server and the client must be capable of passing the accreditation checks discussed in "Routing Example".
The mount(1M) command requires that UID is 0. Thus you can only run mount from a role or user account with an execution profile that includes mount, specifies an effective UID of 0, and runs at ADMIN_LOW. The mount command may need these privileges: sys_mount, file_dac_read, file_dac_write, file_dac_search, file_mac_read, file_mac_write, file_mac_search, net_privaddr, proc_setsl, proc_setclr, and sys_trans_label. See priv_desc(4) for more information on these privileges. See also"Managing Files and File Systems" in Trusted Solaris Administrator's Procedures
The vfstab_adjunct file and mount command with -S option let you specify the security attributes for mounts.
The available security attributes are:
label--the label of the files
forced privileges--the set of forced privileges to be applied to executable files in the mounted filesystem
allowed privileges--the set of allowed privileges to be applied to executable files in the mounted filesystem
label range--the range of labels that can be applied to directories and files in the mounted filesystem
MLD prefix--a substitute for .MLD. as a prefix for multilevel directories