Skip Navigation Links | |
Exit Print View | |
Trusted Extensions Configuration and Administration Oracle Solaris 11.1 Information Library |
Part I Initial Configuration of Trusted Extensions
1. Security Planning for Trusted Extensions
2. Configuration Roadmap for Trusted Extensions
3. Adding the Trusted Extensions Feature to Oracle Solaris (Tasks)
4. Configuring Trusted Extensions (Tasks)
5. Configuring LDAP for Trusted Extensions (Tasks)
Part II Administration of Trusted Extensions
6. Trusted Extensions Administration Concepts
7. Trusted Extensions Administration Tools
8. Security Requirements on a Trusted Extensions System (Overview)
9. Performing Common Tasks in Trusted Extensions
10. Users, Rights, and Roles in Trusted Extensions (Overview)
11. Managing Users, Rights, and Roles in Trusted Extensions (Tasks)
12. Remote Administration in Trusted Extensions (Tasks)
13. Managing Zones in Trusted Extensions
14. Managing and Mounting Files in Trusted Extensions
15. Trusted Networking (Overview)
Trusted Extensions Data Packets
Trusted Extensions Multicast Packets
Trusted Network Communications
Network Commands in Trusted Extensions
Network Configuration Databases in Trusted Extensions
Trusted Network Security Attributes
Network Security Attributes in Trusted Extensions
Host Type and Template Name in Security Templates
Default Label in Security Templates
Domain of Interpretation in Security Templates
Label Range in Security Templates
Auxiliary Labels in Security Templates
Trusted Network Fallback Mechanism
Overview of Routing in Trusted Extensions
Routing Table Entries in Trusted Extensions
Administration of Routing in Trusted Extensions
Choosing Routers in Trusted Extensions
Gateways in Trusted Extensions
Routing Commands in Trusted Extensions
Administration of Labeled IPsec
Labels for IPsec-Protected Exchanges
Label Extensions for IPsec Security Associations
Labels and Accreditation in Tunnel Mode IPsec
Confidentiality and Integrity Protections With Label Extensions
16. Managing Networks in Trusted Extensions (Tasks)
17. Trusted Extensions and LDAP (Overview)
18. Multilevel Mail in Trusted Extensions (Overview)
19. Managing Labeled Printing (Tasks)
20. Devices in Trusted Extensions (Overview)
21. Managing Devices for Trusted Extensions (Tasks)
22. Trusted Extensions Auditing (Overview)
23. Software Management in Trusted Extensions
Creating and Managing a Security Policy
Site Security Policy and Trusted Extensions
Computer Security Recommendations
Physical Security Recommendations
Personnel Security Recommendations
Additional Security References
B. Configuration Checklist for Trusted Extensions
Checklist for Configuring Trusted Extensions
C. Quick Reference to Trusted Extensions Administration
Administrative Interfaces in Trusted Extensions
Oracle Solaris Interfaces Extended by Trusted Extensions
Tighter Security Defaults in Trusted Extensions
Limited Options in Trusted Extensions
D. List of Trusted Extensions Man Pages
Trusted Extensions Man Pages in Alphabetical Order
Oracle Solaris Man Pages That Are Modified by 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 Oracle Solaris OS. Unlike Oracle Solaris, Trusted Extensions 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.
Note - A labeled gateway that is expected to forward packets from adaptive hosts must configure its inbound interface with a netif host type template. For definitions of the adaptive and netif host types, see Host Type and Template Name in Security Templates.
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 Oracle Solaris routing makes choices to optimize the route. Trusted Extensions provides additional software to check security requirements that apply to the route choices. The Oracle Solaris choices that do not satisfy security requirements are skipped.
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 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 an auxiliary label set.
The accreditation check verifies the label range and the CALIPSO or 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 hosts that support labels. When a label is not available from the packet, a default label is assigned to the message from the security template. These labels are then used during accreditation checks. Trusted Extensions enforces several checks on outgoing messages, forwarded messages, and incoming messages.
The following accreditation checks are performed on the sending process or sending zone:
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.
For all destinations, the label of the outgoing packet 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.
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.
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 security template. Otherwise, the packet receives the label that is indicated in the CALIPSO or CIPSO option.
Checks for forwarding a packet proceed similar to source accreditation, as follows:
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.
For all destinations, the label of the outgoing packet 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.
The label of an unlabeled packet must match the destination host's default label.
The label of a labeled packet must be within the destination host's label range.
A labeled gateway that is expected to forward packets from adaptive hosts must configure its inbound interface with a netif host type template. For definitions of the adaptive and netif host types, see Host Type and Template Name in Security Templates.
When a Trusted Extensions system 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 security template. Otherwise, the packet receives the label that is indicated in the labeled option.
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 multilevel 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.