1. Trusted Extensions Administration Concepts
2. Trusted Extensions Administration Tools
3. Getting Started as a Trusted Extensions Administrator (Tasks)
4. Security Requirements on a Trusted Extensions System (Overview)
5. Administering Security Requirements in Trusted Extensions (Tasks)
6. Users, Rights, and Roles in Trusted Extensions (Overview)
7. Managing Users, Rights, and Roles in Trusted Extensions (Tasks)
8. Remote Administration in Trusted Extensions (Tasks)
9. Trusted Extensions and LDAP (Overview)
10. Managing Zones in Trusted Extensions (Tasks)
11. Managing and Mounting Files in Trusted Extensions (Tasks)
12. Trusted Networking (Overview)
13. 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 Open the Trusted Networking Tools
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
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
14. Multilevel Mail in Trusted Extensions (Overview)
15. Managing Labeled Printing (Tasks)
16. Devices in Trusted Extensions (Overview)
17. Managing Devices for Trusted Extensions (Tasks)
18. Trusted Extensions Auditing (Overview)
19. Software Management in Trusted Extensions (Tasks)
A. Quick Reference to Trusted Extensions Administration
The following task map describes tasks to configure the network and to verify the configuration.
|
You must be in the Security Administrator role in the global zone.
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.
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.
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.
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
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 13-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 ...
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.
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.
$ 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 13-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 ...
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.
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.
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 13-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
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.
You must be in the Security Administrator role in the global zone.
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.
$ tnctl -h hostname
This command reads only the information from the chosen option into the kernel. For details about the options, see Example 13-17 and the tnctl(1M) man page.
Note - The tnd service is running only if the ldap service running.
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.
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
$ 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 13-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 13-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