Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Solaris Trusted Extensions Configuration and Administration Oracle Solaris 11 Express 11/10 |
Part I Initial Configuration of Trusted Extensions
1. Security Planning for Trusted Extensions
2. Configuration Roadmap for Trusted Extensions
3. Adding Trusted Extensions Software to the Oracle Solaris OS (Tasks)
4. Configuring Trusted Extensions (Tasks)
5. Configuring LDAP for Trusted Extensions (Tasks)
6. Configuring a Headless System With Trusted Extensions (Tasks)
Part II Administration of Trusted Extensions
7. Trusted Extensions Administration Concepts
8. Trusted Extensions Administration Tools
9. Getting Started as a Trusted Extensions Administrator (Tasks)
10. Security Requirements on a Trusted Extensions System (Overview)
11. Administering Security Requirements in Trusted Extensions (Tasks)
12. Users, Rights, and Roles in Trusted Extensions (Overview)
13. Managing Users, Rights, and Roles in Trusted Extensions (Tasks)
14. Remote Administration in Trusted Extensions (Tasks)
15. Trusted Extensions and LDAP (Overview)
16. Managing Zones in Trusted Extensions (Tasks)
17. Managing and Mounting Files in Trusted Extensions (Tasks)
18. Trusted Networking (Overview)
Trusted Extensions Data Packets
Trusted Network Communications
Network Configuration Databases in Trusted Extensions
Network Commands 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
Security Label Set in Security Templates
Trusted Network Fallback Mechanism
Overview of Routing in Trusted Extensions
Routing Table Entries in Trusted Extensions
Trusted Extensions Accreditation Checks
Destination Accreditation Checks
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
19. Managing Networks in Trusted Extensions (Tasks)
20. Multilevel Mail in Trusted Extensions (Overview)
21. Managing Labeled Printing (Tasks)
22. Devices in Trusted Extensions (Overview)
23. Managing Devices for Trusted Extensions (Tasks)
24. Trusted Extensions Auditing (Overview)
25. Software Management in Trusted Extensions (Reference)
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
Trusted Extensions systems can protect labeled network packets with IPsec. The IPsec packets can be sent with explicit or implicit Trusted Extensions labels. Labels are sent explicitly by using CIPSO IP options and implicitly by using labeled IPsec security associations (SAs). Also, IPsec encrypted packets with different implicit labels can be tunneled across an unlabeled network.
For general IPsec concepts and configuration procedures, see Part III, IP Security, in System Administration Guide: IP Services. For Trusted Extensions modifications to IPsec procedures, see Configuring Labeled IPsec (Task Map).
All communications on Trusted Extensions systems, including IPsec-protected communications, must satisfy security label accreditation checks. The checks are described in Trusted Extensions Accreditation Checks.
The labels on IPsec packets that must pass these checks are the inner label, the wire label, and the key management label:
Application security label – The label of the zone in which the application resides.
Inner label – The label of the unencrypted message data before IPsec AH or ESP headers have been applied. This label can be different from the application security label when the SO_MAC_EXEMPT socket option (MAC-exempt) or multilevel port (MLP) features are being used. When selecting security associations (SAs) and IKE rules that are constrained by labels, IPsec and IKE use this inner label.
By default, the inner label is the same as the application security label. Typically, applications at both ends have the same label. However, for MAC-exempt or MLP communication, this condition might not be true. IPsec configuration settings can define how the inner label is conveyed across the network, that is, they can define the wire label. IPsec configuration settings cannot define the value of the inner label.
Wire label – The label of the encrypted message data after IPsec AH or ESP headers have been applied. Depending on the IKE and IPsec configuration files, the wire label might be different from the inner label.
Key management label – All IKE negotiations between two nodes are controlled at a single label, regardless of the label of application messages that trigger the negotiations. The label of IKE negotiations is defined in the /etc/inet/ike/config file on a per-IKE rule basis.
IPsec label extensions are used on Trusted Extensions systems to associate a label with the traffic that is carried inside a security association (SA). By default, IPsec does not use label extensions and therefore ignores labels. All traffic between two systems flows through a single SA, regardless of the Trusted Extensions label.
Label extensions enable you to do the following:
Configure a different IPsec SA for use with each Trusted Extensions label. This configuration effectively provides an additional mechanism for conveying the label of traffic that travels between two multilevel systems.
Specify an on-the-wire label for IPsec encrypted message text that is different from the unencrypted form of the text. This configuration supports the transmission of encrypted confidential data through a less secure network.
Suppress the use of CIPSO IP options in IP packets. This configuration enables labeled traffic to traverse CIPSO-unaware or CIPSO-hostile networks.
You can specify whether to use label extensions automatically through IKE as described in Label Extensions for IKE, or manually through the ipseckey command. For details on the label extensions features, see the ipseckey(1M) man page.
When using label extensions, SA selection for outbound traffic includes the inner sensitivity label as part of the match. The security label of inbound traffic is defined by the security label of received packet's SA.
IKE on Trusted Extensions systems supports the negotiation of labels for SAs with label-aware peers.
You can control this mechanism by using the following keywords in the /etc/inet/ike/config file:
label_aware – Enables the in.iked daemon's use of Trusted Extensions label interfaces and the negotiation of labels with peers.
single_label – Indicates that the peer does not support the negotiation of labels for SAs.
multi_label – Indicates that the peer supports the negotiation of labels for SAs. IKE creates a new SA for each additional label that IKE encounters in the traffic between two nodes.
wire_label inner – Causes the in.iked daemon to create labeled SAs where the wire label is the same as the inner label. The key management label is ADMIN_LOW when the daemon is negotiating with cipso peers. The key management label is the peer's default label when the daemon is negotiating with unlabeled peers. Normal Trusted Extensions rules are followed for inclusion of the CIPSO IP options in transmitted packets.
wire_label label – Causes the in.iked daemon to create labeled SAs where the wire label is set to label, regardless of the value of the inner label. The in.iked daemon performs key management negotiations at the specified label. Normal Trusted Extensions rules are followed for inclusion of CIPSO IP options in transmitted packets.
wire_label none label – Causes behavior similar to wire_label label, except that CIPSO IP options are suppressed on transmitted IKE packets and data packets under the SA.
For more information, see the ike.config(4) man page.
When application data packets are protected by IPsec in tunnel mode, the packets contain multiple IP headers.
The IKE protocol's IP header contains the same source and destination address pair as the application data packet's outer IP header.
Trusted Extensions uses the inner IP header addresses for inner label accreditation checks. Trusted Extensions performs wire and key management label checks by using the outer IP header addresses. For information about the accreditation checks, see Trusted Extensions Accreditation Checks.
The following table explains how IPsec confidentiality and integrity protections apply to the security label with various configurations of label extensions.
|
Note - You cannot use IPsec AH integrity protections to protect the CIPSO IP option if CIPSO-aware routers might strip or add the CIPSO IP option as a message travels through the network. Any modification to the CIPSO IP option will invalidate the message and cause a packet that is protected by AH to be dropped at the destination.