Solaris Trusted Extensions Administrator's Procedures
Previous Next

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

The following task map describes tasks to configure the network and to verify the configuration.

Task

Description

For Instructions

Configure static routes.

Manually describes the best route from one host to another host.

How to Configure Routes With Security Attributes

Check the accuracy of the local network databases.

Uses the tnchkdb command to check the syntactic validity of the local network databases.

How to Check the Syntax of Trusted Network Databases

Compare the network database entries with the entries in the kernel cache.

Uses the tninfo command to determine if the kernel cache has been updated with the latest database information.

How to Compare Trusted Network Database Information With the Kernel Cache

Synchronize the kernel cache with the network databases.

Uses the tnctl command to update the kernel cache with up-to-date network database information on a running system.

How to Synchronize the Kernel Cache With Trusted Network Databases

How to Configure Routes With Security Attributes

Before You Begin

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

  1. Add every destination host and gateway that you are using to route packets over the trusted network.

    The addresses are added to the local /etc/hosts file, or to its equivalent on the LDAP server. Use the Computers and Networks tool in the Solaris Management Console. The Files scope modifies the /etc/hosts file. The LDAP scope modifies the entries on the LDAP server. For details, see How to Add Hosts to the System's Known Network.

  2. Assign each destination host, network, and gateway to a security template.

    The addresses are added to the local /etc/security/tsol/tnrhdb file, or to its equivalent on the LDAP server. Use the Security Templates tool in the Solaris Management Console. For details, see How to Assign a Security Template to a Host or a Group of Hosts.

  3. Set up the routes.

    In a terminal window, use the route add command to specify routes.

    The first entry sets up a default route. The entry specifies a gateway's address, 192.168.113.1, to use when no specific route is defined for either the host or the packet's destination.

    # route add default 192.168.113.1 -static

    For details, see the route(1M) man page.

  4. Set up one or more network entries.

    Use the -secattr flag to specify security attributes.

    In the following list of commands, the second line shows a network entry. The third line shows a network entry with a label range of PUBLIC to CONFIDENTIAL : INTERNAL USE ONLY.

    # route add default 192.168.113.36
    # route add -net 192.168.102.0 gateway-101
    # route add -net 192.168.101.0 gateway-102 \
    -secattr min_sl=“PUBLIC”,max_sl=”CONFIDENTIAL : INTERNAL USE ONLY”,doi=1
  5. Set up one or more host entries.

    The new fourth line shows a host entry for the single-label host, gateway-pub. gateway-pub has a label range of PUBLIC to PUBLIC.

    # route add default 192.168.113.36
    # route add -net 192.168.102.0 gateway-101
    # route add -net 192.168.101.0 gateway-102 \
    -secattr min_sl="PUBLIC",max_sl="CONFIDENTIAL : INTERNAL USE ONLY",doi=1
    # route add -host 192.168.101.3 gateway-pub \
    -secattr min_sl="PUBLIC",max_sl="PUBLIC",doi=1
Example 19-14 Adding a Route With a Label Range of CONFIDENTIAL : INTERNAL USE ONLY to CONFIDENTIAL : RESTRICTED

The following route command adds to the routing table the hosts at 192.168.115.0 with 192.168.118.39 as its gateway. The label range is from CONFIDENTIAL : INTERNAL USE ONLY to CONFIDENTIAL : RESTRICTED, and the DOI is 1.

$ route add -net 192.168.115.0 192.168.118.39 \
-secattr min_sl="CONFIDENTIAL : INTERNAL USE ONLY",max_sl="CONFIDENTIAL : RESTRICTED",doi=1

The result of the added hosts is shown with the netstat -rR command. In the following excerpt, the other routes are replaced by ellipses (...).

$ netstat -rRn
...
192.168.115.0        192.168.118.39        UG       0      0  
        min_sl=CNF : INTERNAL USE ONLY,max_sl=CNF : RESTRICTED,DOI=1,CIPSO
...

How to Check the Syntax of Trusted Network Databases

The tnchkdb command checks that the syntax of each network database is accurate. The Solaris Management Console runs this command automatically when you use the Security Templates tool or the Trusted Network Zones tool. Typically, you run this command to check the syntax of database files that you are configuring for future use.

Before You Begin

You must be in the global zone in a role that can check network settings. The Security Administrator role and the System Administrator role can check these settings.

  • In a terminal window, run the tnchkdb command.
    $ tnchkdb [-h tnrhdb-path] [-t tnrhtp-path] [-z tnzonecfg-path]
    checking /etc/security/tsol/tnrhtp ...
    checking /etc/security/tsol/tnrhdb ...
    checking /etc/security/tsol/tnzonecfg ...
Example 19-15 Testing the Syntax of a Trial Network Database

In this example, the security administrator is testing a network database file for possible use. Initially, the administrator uses the wrong option. The results of the check are printed on the line for the tnrhdb file:

$ tnchkdb -h /opt/secfiles/trial.tnrhtp
checking /etc/security/tsol/tnrhtp ...
checking /opt/secfiles/trial.tnrhtp ...
line 12: Illegal name: min_sl=ADMIN_LOW;max_sl=ADMIN_HIGH
line 14: Illegal name: min_sl=ADMIN_LOW;max_sl=ADMIN_HIGH
checking /etc/security/tsol/tnzonecfg ...

When the security administrator checks the file by using the -t option, the command confirms that the syntax of the trial tnrhtp database is accurate:

$ tnchkdb -t /opt/secfiles/trial.tnrhtp
checking /opt/secfiles/trial.tnrhtp ...
checking /etc/security/tsol/tnrhdb ...
checking /etc/security/tsol/tnzonecfg ...

How to Compare Trusted Network Database Information With the Kernel Cache

The network databases might contain information that is not cached in the kernel. This procedure checks that the information is identical. When you use the Solaris Management Console to update the network, the kernel cache is updated with network database information. The tninfo command is useful during testing and for debugging.

Before You Begin

You must be in the global zone in a role that can check network settings. The Security Administrator role and the System Administrator role can check these settings.

  • In a terminal window, run the tninfo command.
    • tninfo -h hostname displays the IP address and template for the specified host.

    • tninfo -t templatename displays the following information:

      template: template-name
      host_type: either CIPSO or UNLABELED
      doi: 1
      min_sl: minimum-label
      hex: minimum-hex-label
      max_sl: maximum-label
      hex:maximum-hex-label
    • tninfo -m zone-name displays the multilevel port (MLP) configuration of a zone.

Example 19-16 Displaying Multilevel Ports on a Host

In this example, a system is configured with several labeled zones. All zones share the same IP address. Some zones are also configured with zone-specific addresses. In this configuration, the TCP port for web browsing, port 8080, is an MLP on a shared interface in the public zone. The administrator has also set up telnet, TCP port 23, to be an MLP in the public zone. Because these two MLPs are on a shared interface, no other zone, including the global zone, can receive packets on the shared interface on ports 8080 and 23.

In addition, the TCP port for ssh, port 22, is a per-zone MLP in the public zone. The public zone's ssh service can receive any packets on its zone-specific address within the address's label range.

The following command shows the MLPs for the public zone:

$ tninfo -m public
private: 22/tcp
shared:  23/tcp;8080/tcp

The following command shows the MLPs for the global zone. Note that ports 23 and 8080 cannot be MLPs in the global zone because the global zone shares the same address with the public zone:

$ tninfo -m global
private: 111/tcp;111/udp;514/tcp;515/tcp;631/tcp;2049/tcp;
         6000-6003/tcp;38672/tcp;60770/tcp;
shared:  6000-6003/tcp

How to Synchronize the Kernel Cache With Trusted Network Databases

When the kernel has not been updated with trusted network database information, you have several ways to update the kernel cache. The Solaris Management Console runs this command automatically when you use the Security Templates tool or the Trusted Network Zones tool.

Before You Begin

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

  • To synchronize the kernel cache with network databases, run one of the following commands:
    • Restart the tnctl service.

      Caution - Do not use this method on systems that obtain their trusted network database information from an LDAP server. The local database information would overwrite the information that is obtained from the LDAP server.


      $ svcadm restart svc:/network/tnctl

      This command reads all information from the local trusted network databases into the kernel.

    • Update the kernel cache for your recently added entries.
      $ tnctl -h hostname

      This command reads only the information from the chosen option into the kernel. For details about the options, see Example 19-17 and the tnctl(1M) man page.

    • Change the tnd polling interval.

      This does not update the kernel cache. However, you can shorten the polling interval to update the kernel cache more frequently. For details, see the example in the tnd(1M) man page.

    • Refresh the tnd.

      This Service Management Facility (SMF) command triggers an immediate update of the kernel with recent changes to trusted network databases.

      $ svcadm refresh svc:/network/tnd
    • Restart the tnd by using SMF.
      $ svcadm restart svc:/network/tnd

      Caution - Avoid running the tnd command to restart the tnd. This command can interrupt communications that are currently succeeding.


Example 19-17 Updating the Kernel With Your Latest tnrhdb Entries

In this example, the administrator has added three addresses to the local tnrhdb database. First, the administrator removed the 0.0.0.0 wildcard entry.

$ tnctl -d -h 0.0.0.0:admin_low

Then, the administrator views the format of the final three entries in the /etc/security/tsol/tnrhdb database:

$ tail /etc/security/tsol/tnrhdb
#\:\:0:admin_low
127.0.0.1:cipso
#\:\:1:cipso
192.168.103.5:admin_low
192.168.103.0:cipso
0.0.0.0/32:admin_low

Then, the administrator updates the kernel cache:

$ tnctl -h 192.168.103.5
tnctl -h 192.168.103.0
tnctl -h 0.0.0.0/32

Finally, the administrator verifies that the kernel cache is updated. The output for the first entry is similar to the following:

$ tninfo -h 192.168.103.5
IP Address: 192.168.103.5
Template: admin_low
Example 19-18 Updating Network Information in the Kernel

In this example, the administrator updates the trusted network with a public print server, and then checks that the kernel settings are correct.

$ tnctl -h public-print-server
$ tninfo -h public-print-server
IP Address: 192.168.103.55
Template: PublicOnly
$ tninfo -t PublicOnly
==================================
Remote Host Template Table Entries
----------------------------------
template: PublicOnly
host_type: CIPSO
doi: 1
min_sl: PUBLIC
hex: 0x0002-08-08
max_sl: PUBLIC
hex: 0x0002-08-08
Previous Next