Overview of Routing in Trusted Extensions
In Trusted Extensions, routes between hosts on different networks must maintain security at
each step in the transmission. Trusted Extensions adds extended security attributes to the routing
protocols in the Solaris OS. Unlike the Solaris OS, this Trusted Extensions
release does not support dynamic routing. For details about specifying static routing, see the
-p option in the route(1M) man page.
Gateways and routers route packets. In this discussion, the terms “gateway” and “router”
are used interchangeably.
For communications between hosts on the same subnet, accreditation checks are performed at
endpoints only because no routers are involved. Label range checks are performed at
the source. If the receiving host is running Trusted Extensions software, label range
checks are also performed at the destination.
When the source and destination hosts are on different subnets, the packet is
sent from the source host to a gateway. The label range of
the destination and the first-hop gateway is checked at the source when a
route is selected. The gateway forwards the packet to the network where the
destination host is connected. A packet might go through several gateways before reaching
the destination.
Background on Routing
On Trusted Extensions gateways, label range checks are performed in certain cases. A
Trusted Extensions system that is routing a packet between two unlabeled hosts compares
the default label of the source host to the default label of the
destination host. When the unlabeled hosts share a default label, the packet is
routed.
Each gateway maintains a list of routes to all destinations. Standard Solaris
routing makes choices to optimize the route. Trusted Extensions provides additional software to check
security requirements that apply to the route choices. The Solaris choices that do
not satisfy security requirements are skipped.
Routing Table Entries in Trusted Extensions
The routing table entries in Trusted Extensions can incorporate security attributes. Security attributes
can include a cipso keyword. Security attributes must include a maximum label, a
minimum label, and a DOI.
For entries that do not provide security attributes, the attributes in the gateway's
security template are used.
Trusted Extensions Accreditation Checks
Trusted Extensions software determines the suitability of a route for security purposes. The
software runs a series of tests called accreditation checks on the source host,
the destination host, and the intermediate gateways.
Note - In the following discussion, an accreditation check for a label range also means
a check for a security label set.
The accreditation check verifies the label range and CIPSO label information. The security
attributes for a route are obtained from the routing table entry, or from
the security template of the gateway if the entry has no security attributes.
For incoming communications, the Trusted Extensions software obtains labels from the packets themselves,
whenever possible. Obtaining labels from packets is only possible when the messages are
sent from systems that support labels. When a label is not available from
the packet, a default label is assigned to the message from trusted networking
database files. These labels are then used during accreditation checks. Trusted Extensions enforces
several checks on outgoing messages, forwarded messages, and incoming messages.
Source Accreditation Checks
The following accreditation checks are performed on the sending process or sending zone:
For all destinations, the label of the data must be within the label range of the next hop in the route, that is, the first hop. And, the label must be contained in the first-hop gateway's security attributes.
For all destinations, the DOI of an outgoing packet must match the DOI of the destination host. The DOI must also match the DOI of all hops along the route, including its first-hop gateway.
When the destination host is an unlabeled host, one of the following conditions must be satisfied:
The sending host's label must match the destination host's default label.
The sending host is privileged to perform cross-label communication, and the sender's label dominates the destination's default label.
The sending host is privileged to perform cross-label communication, and the sender's label is ADMIN_LOW. That is, the sender is sending from the global zone.
Note - A first-hop check occurs when a message is being sent through a gateway
from a host on one network to a host on another network.
Gateway Accreditation Checks
On a Trusted Extensions gateway system,the following accreditation checks are performed for the
next-hop gateway:
If the incoming packet is unlabeled, the packet inherits the source host's default label from the tnrhdb entry. Otherwise, the packet receives the indicated CIPSO label.
Checks for forwarding a packet proceed similar to source accreditation:
For all destinations, the label of the data must be within the label range of the next hop. And, the label must be contained in the security attributes of the next-hop host.
For all destinations, the DOI of an outgoing packet must match the DOI of the destination host. The DOI must also match the DOI of the next-hop host.
The label of an unlabeled packet must match the destination host's default label.
The label of a CIPSO packet must be within the destination host's label range.
Destination Accreditation Checks
When a Trusted Extensions host receives data, the software performs the following checks:
If the incoming packet is unlabeled, the packet inherits the source host's default label from the tnrhdb entry. Otherwise, the packet receives the indicated CIPSO label.
The label and DOI for the packet must be consistent with the destination zone or destination process's label and DOI. The exception is when a process is listening on a port. The listening process can receive a packet if the process is privileged to perform cross-label communications, and the process is either in the global zone or has a label that dominates the packet's label.
