JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Trusted Extensions Configuration and Administration     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information

Preface

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)

19.  Managing Networks in Trusted Extensions (Tasks)

Managing the Trusted Network (Task Map)

Configuring Trusted Network Databases (Task Map)

How to Determine If You Need Site-Specific Security Templates

How to Construct a Remote Host Template

How to Add Hosts to the System's Known Network

How to Assign a Security Template to a Host or a Group of Hosts

How to Limit the Hosts That Can Be Contacted on the Trusted Network

Configuring Routes and Checking Network Information in Trusted Extensions (Task Map)

How to Configure Routes With Security Attributes

How to Check the Syntax of Trusted Network Databases

How to Compare Trusted Network Database Information With the Kernel Cache

How to Synchronize the Kernel Cache With Trusted Network Databases

Configuring Labeled IPsec (Task Map)

How to Apply IPsec Protections in a Multilevel Trusted Extensions Network

How to Configure a Tunnel Across an Untrusted Network

Troubleshooting the Trusted Network (Task Map)

How to Verify That a Host's Interfaces Are Up

How to Debug the Trusted Extensions Network

How to Debug a Client Connection to the LDAP Server

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)

A.  Site Security Policy

Creating and Managing a Security Policy

Site Security Policy and Trusted Extensions

Computer Security Recommendations

Physical Security Recommendations

Personnel Security Recommendations

Common Security Violations

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

Glossary

Index

Configuring Trusted Network Databases (Task Map)

Trusted Extensions software includes the tnrhtp and tnrhdb databases. These databases provide labels for remote hosts that contact the system.

The following task map describes tasks to create security templates and apply them to hosts.

Task
Description
For Instructions
Determine if your site requires customized security templates.
Evaluates the existing templates for the security requirements of your site.
Modify security templates.
Modifies the definitions of security attributes in your trusted network by modifying the trusted network databases.
Changes the DOI to a value different from 1.
Creates a security template for labeled hosts that restrict communication between other hosts to a single label.
Creates a security template for unlabeled hosts that operate as single-label gateways.
Creates a security template for hosts with a restricted label range.
Creates a security template for a host that specifies a set of discrete labels in its label range.
Creates a security template for unlabeled systems and networks.
Creates a security template for two developer systems.
Add hosts to the known network.
Adds systems and networks to the trusted network.
Provide remote host access by using wildcard entries.
Allows hosts within a range of IP addresses to communicate with a system by indirectly assigning each host to the same security template.
Change the admin_low wildcard entry in the tnrhdb file.
Increases security by replacing the wildcard entry with specific addresses for the host to contact at boot time.
Increases security by replacing the wildcard entry with a network of labeled hosts as the default.
Create an entry for the host address 0.0.0.0
Configures a Sun Ray server to accept the initial contact from a remote client
Assign security templates.
Associates a template with an IP address or list of contiguous IP addresses.

How to Determine If You Need Site-Specific Security Templates

Before You Begin

You must be in the Security Administrator role in the global zone.

  1. Familiarize yourself with the Trusted Extensions templates.

    Read the tnrhtp file on a local host. The comments in the file are helpful.

    • The default templates match any installation. The label range for each template is ADMIN_LOW to ADMIN_HIGH.

    • The cipso template defines a CIPSO host type whose DOI is 1. The label range for the template is ADMIN_LOW to ADMIN_HIGH.

    • The admin_low template defines an unlabeled host whose DOI is 1. The template's default label is ADMIN_LOW. The label range for the template is ADMIN_LOW to ADMIN_HIGH. In the default configuration, the address 0.0.0.0 is assigned to this template. Therefore, all non-CIPSO hosts are treated as hosts that operate at the ADMIN_LOW security label.

  2. Keep the default templates.

    For support purposes, do not delete or modify the default templates. You can change the host that is assigned these default templates. For an example, see How to Limit the Hosts That Can Be Contacted on the Trusted Network.

  3. Create new templates if you want to do any of the following:
    • Limit the label range of a host or a group of hosts.

    • Create a single-label host.

    • Create a host that recognizes a few discrete labels.

    • Use a different DOI than 1.

    • Require a default label for unlabeled hosts that is not ADMIN_LOW.

    For details, see How to Construct a Remote Host Template.

How to Construct a Remote Host Template

Before You Begin

You must be in the global zone in a role that can modify network security. For example, roles that are assigned the Information Security or Network Security rights profiles can modify security settings. The Security Administrator role includes these profiles.

  1. Examine the templates in the tnrhtp database.

    View which hosts and which networks are already assigned this template.

    # The following is the default template used on the system.
    # 
    #_unlab:host_type=unlabeled;doi=1;def_label=ADMIN_LOW;min_sl=ADMIN_LOW;
    max_sl=ADMIN_HIGH
    #
    # Default for locally plumbed interfaces
    cipso:host_type=cipso;doi=1;min_sl=ADMIN_LOW;max_sl=ADMIN_HIGH;
    #
    admin_low:host_type=unlabeled;doi=1;min_sl=ADMIN_LOW;max_sl=ADMIN_HIGH;
    def_label=ADMIN_LOW;
  2. Examine the template assignments in the tnrhdb database.

    View which hosts and which networks are assigned which template.

    # The following are the boot-time defaults.  These establish all IPv4 and
    # IPv6 addresses as unlabeled.  Both are removed if this file contains any
    # non-blank entries.
    #
    #0.0.0.0/0:_unlab
    #\:\:0/0:_unlab
    #
    # The following is a sample 32-bit match for the literal address 0.0.0.0,
    # not a wildcard.  Uncomment this if the global zone should respond
    # to 0.0.0.0 (literal), such as for dhcp or some third-party network
    # applications.
    #
    #0.0.0.0/32:admin_low
    #
    # Default wildcard value shipped with system. This allows the global zone
    # of the system to obtain various services during initial boot. Administrators
    # should remove this wildcard entry after the system is fully configured.
    #
    0.0.0.0:admin_low
    #\:\:0:admin_low
    127.0.0.1:cipso
    #\:\:1:cipso
  3. Determine the hexadecimal version of the any label other than ADMIN_HIGH and ADMIN_LOW.

    Use the atohexlabel command. For more information, see the atohexlabel(1M) man page.

    # atohexlabel public
    0x0002-08-08
  4. Create a template.

    If the provided templates do not sufficiently describe the hosts that can be in communication with this system, create new templates. Before assigning hosts to the templates, create all the templates that your site requires.

    1. Back up the tnrhtp database.
      # cd /etc/security/tsol
      # cp tnrhtp tnrhtp.orig
    2. Modify the tnrhtp database.

      See the following examples.

  5. Verify the syntax of the changes to the databases
    # tnchkdb
         checking /etc/security/tsol/tnrhtp ...
         checking /etc/security/tsol/tnrhdb ...
         checking /etc/security/tsol/tnzonecfg ...

Example 19-1 Creating a Security Template With a Different DOI Value

In this example, the security administrator's network has a DOI whose value is different from 1. The team that initially configured the system has completed Configure the Domain of Interpretation.

First, the security administrator confirms the value of the DOI in the /etc/system file:

# grep doi /etc/system
set default_doi = 4

Then, for every template that the administrator creates, the value of doi is set to 4. For the single-label system that is described in Example 19-2, the security administrator creates the following template:

## tnrhtp database
...
cipso_public:host_type=cipso;doi=4;min_sl=0x0002-08-08;
max_sl=0x0002-08-08;

Finally, the administrator verifies the syntax of the database:

# tnchkdb

Example 19-2 Creating a Security Template That Has a Single Label

In this example, the security administrator wants to create a gateway that can only pass packets at a single label, PUBLIC.

First, the gateway host and IP address are added to the /etc/hosts file.

## /etc/hosts
...
gateway-1     192.168.131.75

Then, the template for the gateway is added to the tnrhtp database:

## tnrhtp database
...
cipso_public:host_type=cipso;doi=1;min_sl=0X0002-08-08;max_sl=0X0002-08-08;

Then, the gateway-1 host is assigned to the template in the tnrhdb database:

## tnrhdb database
...
# gateway-1
192.168.131.75:cipso_public

Finally, the administrator verifies the syntax of the databases:

# tnchkdb

Example 19-3 Creating a Security Template for an Unlabeled Router

Any IP router can forward messages with CIPSO labels even though the router does not explicitly support labels. Such an unlabeled router needs a default label to define the level at which connections to the router, perhaps for router management, need to be handled. In this example, the security administrator creates a router that can forward traffic at any label, but all direct communication with the router is handled at the default label, PUBLIC.

First, the router and its IP address are added to the /etc/hosts file.

## /etc/hosts
...
router-1    192.168.131.82

Then, its template is added to the tnrhtp database:

## tnrhtp database
...
unl_public:host_type=unlabeled;doi=1;def_label=0x0002-08-08;
min_sl=ADMIN_LOW;max_sl=ADMIN_HIGH

Then, the router-1 router is assigned to the template in the tnrhdb database:

## tnrhdb database
...
# router-1
192.168.131.82:unl_public

Finally, the administrator verifies the syntax of the databases:

# tnchkdb

Example 19-4 Creating a Security Template That Has a Limited Label Range

In this example, the security administrator wants to create a gateway that restricts packets to a narrow label range. The administrator creates a template and assigns the gateway host to the template.

First, the router and its IP address are added to the /etc/hosts file.

## /etc/hosts
...
gateway-ir    192.168.131.78

Then, its template is added to the tnrhtp database:

## tnrhtp database
...
cipso_iuo_rstrct:host_type=cipso;doi=1;min_sl=0x0004-08-48;max_sl=0x0004-08-78;

Then, the gateway-ir gateway is assigned to the template in the tnrhdb database.

# gateway-ir
192.168.131.78:cipso_iuo_rstrct

Finally, the administrator verifies the syntax of the databases:

# tnchkdb

Example 19-5 Creating a Security Template That Has a Security Label Set

In this example, the security administrator wants to create a security template that recognizes two labels only.

First, each host and IP address that is going to use this template is added to the /etc/hosts file.

## /etc/hosts
...
host-slset1    192.168.132.21
host-slset2    192.168.132.22
host-slset3    192.168.132.23
host-slset4    192.168.132.24

Then, the template is added to the tnrhtp database:

## tnrhtp database
...
cipso_pub_rstrct:host_type=cipso;doi=1;min_sl=0x0002-08-08;
max_sl=0x0004-08-78;sl_set=0x0002-08-08,0x0004-08-78;

Then, the range of IP addresses are assigned to the template by using a wildcard in the tnrhdb database:

192.168.132.0/17:cipso_pub_rstrct

Finally, the administrator verifies the syntax of the databases:

# tnchkdb

Example 19-6 Creating an Unlabeled Template at the Label PUBLIC

In this example, the security administrator allows a subnetwork of Oracle Solaris systems to have the PUBLIC label in the trusted network. The template has the following values:

## tnrhtp database
...
public:host_type=unlabeled;doi=1;def_label=0x0002-08-08;
min_sl=0x0002-08-08;max_sl=0x0002-08-08
## tnrhdb database
...
10.10.0.0/16:public

All systems on the 10.10.0.0 subnetwork are handled at the label PUBLIC.

Example 19-7 Creating a Labeled Template for Developers

In this example, the security administrator creates a SANDBOX template. This template is assigned to systems that are used by developers of trusted software. The two systems that are assigned this template create and test labeled programs. However, their tests do not affect the other labeled systems, because the label SANDBOX is disjoint from the other labels on the network.

## tnrhtp database
...
cipso_sandbox:host_type=cipso;doi=1;min_sl=0x0005-05-05;max_sl=0x0005-05-05;
## tnrhdb database
...
# DevMachine1
196.168.129.129:cipso_sandbox
# DevMachine2
196.168.129.102:cipso_sandbox

The developers who use these systems can communicate with each other at the label SANDBOX.

How to Add Hosts to the System's Known Network

You add hosts and groups of hosts to the /etc/hosts file. This procedure is provided here for your convenience. After the hosts are known, you then assign the hosts to a security template.

Before You Begin

You must be in an administrator who can manage networks. For example, roles that include the Network Management or System Administrator rights profiles can manage networks.

  1. Add individual hosts that this system can contact.
    # vi /etc/hosts
    
    ...
    192.168.111.121   ahost
  2. Add a group of hosts that this system can contact.
    # vi /etc/hosts
    
    ...
    192.168.111.0   111-network

How to Assign a Security Template to a Host or a Group of Hosts

Before You Begin

You must be in the Security Administrator role in the global zone.

The security template must exist in the tnrhtp database. All hosts that you want to assign to a template must exist in the /etc/hosts file. For details, see How to Add Hosts to the System's Known Network.

  1. Before you modify the tnrhdb database, back it up.
    # cd /etc/security/tsol
    # cp tnrhdb tnrhdb.orig
  2. To assign a template to one host, type the host IP address and the template name in the following format:
    IP-address:templatename

    For example, the following IP address is assigned the CIPSO template:

    ## tnrhdb database
    192.168.1.2:cipso
  3. To assign a template to a group of hosts, type the IP address and the template name in the following format:
    IP-address:templatename

    For example, the following subnets are assigned the CIPSO template:

    ## tnrhdb database
    192.168.113.0:cipso
    192.168.75.0:cipso

    In the following example, the wildcard entry covers the address range of 192.168.113.0 to 192.168.113.127. The address includes 192.168.113.100.

    ## tnrhdb database
    192.168.113.100/25:cipso

    In the following example, the wildcard entry covers contiguous IPv6 addresses from 2001:a08:3903:200::0 to 2001:a08:3903:2ff:ffff:ffff:ffff:ffff. The address includes 2001:a08:3903:201:20e:cff:fe08:58c..

    ## tnrhdb database
    2001:a08:3903:200::0/56:cipso

How to Limit the Hosts That Can Be Contacted on the Trusted Network

This procedure protects labeled hosts from being contacted by arbitrary unlabeled hosts. When Trusted Extensions is installed, this default template defines every host on the network. Use this procedure to enumerate specific unlabeled hosts.

The local tnrhdb file on each system is used to contact the network at boot time. By default, every host that is not provided with a CIPSO template is defined by the admin_low template. This template assigns every system that is not otherwise defined (0.0.0.0) to be an unlabeled system with the default label of admin_low.


Caution

Caution - The default admin_low template can be a security risk on a Trusted Extensions network. If site security requires strong protection, the security administrator can remove the 0.0.0.0 wildcard entry after the system is installed. The entry must be replaced with entries for every host that the system contacts during boot.

For example, DNS servers, home directory servers, audit servers, broadcast and multicast addresses, and routers must be in the local tnrhdb file after the 0.0.0.0 wildcard entry is removed.

If an application initially recognizes clients at the host address 0.0.0.0, then you must add the 0.0.0.0/32:admin_low host entry to the tnrhdb database. For example, to receive initial connection requests from potential Sun Ray clients, Sun Ray servers must include this entry. Then, when the server recognizes the clients, the clients are provided an IP address and connected as CIPSO clients.


Before You Begin

You must be in the Security Administrator role in the global zone.

All hosts that are to be contacted at boot time must exist in the /etc/hosts file.

  1. Back up the tnrhdb database.
  2. Assign the admin_low template to every host that can be contacted at boot.
    • Include every unlabeled host that must be contacted at boot time.

    • Include every on-link router that is not running Trusted Extensions, through which this host must communicate.

    • Comment out the 0.0.0.0:admin_low entry.

  3. Modify the hosts that are assigned to the cipso template.

    Add each labeled host that must be contacted at boot time.

    • Include every on-link router that is running Trusted Extensions, through which this host must communicate

    • Make sure that all network interfaces are assigned to the template.

    • Include broadcast addresses.

    • Include the ranges of labeled hosts that must be contacted at boot time.

    See Example 19-9 for a sample database.

  4. Verify that the host assignments allow the system to boot.

Example 19-8 Changing the Label of the 0.0.0.0 tnrhdb Entry

In this example, the security administrator creates a public gateway system. The administrator removes the 0.0.0.0 entry from the admin_low template and assigns the entry to an unlabeled template that is named public. The system then recognizes any system that is not listed in its tnrhdb file as an unlabeled system with the security attributes of the public security template.

## tnrhdb database
...
0.0.0.0:public

The following entry in the tnrhtp database describes the unlabeled template that was created specifically for public gateways.

## tnrhtp database
...
public:host_type=unlabeled;doi=1;def_label=0x0002-08-08;
min_sl=0x0002-08-08;max_sl=0x0002-08-08

Example 19-9 Enumerating Computers to Contact During Boot in the tnrhdb Database

The following example shows the local tnrhdb database with entries for a host with two network interfaces. The host communicates with another network and with routers.

127.0.0.1:cipso       Loopback address
192.168.112.111:cipso Interface 1 of this host
192.168.113.111:cipso Interface 2 of this host
192.168.113.6:cipso   Audit server
192.168.112.255:cipso Subnet broadcast address
192.168.113.255:cipso Subnet broadcast address
192.168.113.1:cipso   Router
192.168.117.0:cipso   Another Trusted Extensions network
192.168.112.12:public Specific network router
192.168.113.12:public Specific network router
224.0.0.2:public      Multicast address
255.255.255.255:admin_low Broadcast address

Example 19-10 Making the Host Address 0.0.0.0 a Valid tnrhdb Entry

In this example, the security administrator configures a Sun Ray server to accept initial connection requests from potential clients. The server is using a private topology and is using the defaults:

# utadm -a bge0

The server's tnhrdb database appears similar to the following. The entry that allows initial connection requests is highlighted:

## tnrhdb database
## Sun Ray server address
       192.168.128.1:cipso
## Sun Ray client addresses on 192.168.128 network
       192.168.128.0/24:admin_low
## Initial address for new clients
       0.0.0.0/32:admin_low
## Default wildcard address
0.0.0.0:admin_low
Other addresses to be contacted at boot
# tnchkdb -h /etc/security/tsol/tnrhdb

After this phase of testing succeeds, the administrator makes the configuration more secure by removing the default wildcard address, checks the syntax of the tnrhdb database, and tests again. The final tnhrdb database appears similar to the following:

## tnrhdb database
## Sun Ray server address
       192.168.128.1:cipso
## Sun Ray client addresses on 192.168.128 network
       192.168.128.0/24:admin_low
## Initial address for new clients
       0.0.0.0/32:admin_low
## 0.0.0.0:admin_low - no other systems can enter network at admin_low
Other addresses to be contacted at boot