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 that 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 starts 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 Label
Maximum Label
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, the Trusted Solaris environment 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, the 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 work in the following manner:
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 security attributes are missing, 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 security attributes are still 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 below. Figure 3-4 shows the routing diagram and shows the routing table. There are three potential routes between Host 1 and Host 2.
Route |
First hop gateway |
RIP Metric |
Min Label |
Max Label |
DOI |
CIPSO |
---|---|---|---|---|---|---|
1 |
Gateway 1 |
3 |
C |
S |
|
|
2 |
Gateway 3 |
4 |
|
|
|
Y |
3 |
Gateway 5 |
6 |
|
|
|
|
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 broader label range of ADMIN_LOW
to ADMIN_HIGH
. Datagrams using route #2 must 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.
To display the contents of the routing table, use the netstat --R command. To make a manual change to the routing table, use the route command with the add or delete option. For example, the following route command 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, a Label range from C to TS, a RIPSO label = top_secret sci, and a RIPSO error = genser;sci.
$ 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
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 (top_secret sci), ripso_error=0xa0000000 (genser;sci), metric=3,min_sl=ADMIN_LOW,max_sl=S,doi=3 ...
Secure data can be routed 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 the following 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 a label 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.