SunScreen 3.2 Administrator's Overview

tsolpeerinfo Service

When two Trusted Solaris systems communicate with each other using the TSOL protocol, they typically use rpc program 110002 to exchange process attributes for peer processes. The entry in /etc/rpc is tsolpeerinfo 110002 rpc.getpeerinfo peerinfod.

If this service is blocked, services do not work. A connection is established, but Trusted Solaris waits for a response from peerinfod for additional information. Until it gets that response, the connection cannot proceed. The tsolpeerinfo service prevents this problem by ensuring that this service can be initiated from both sides of a connection through a firewall.

A server (ftpd, telnetd, etc., for example) spawned by inetd requests the audit attributes of a connecting client from a Trusted Solaris system. The server sends a getpeerinfo RPC back to the client, which responds with the required information. For example, to allow telnet through the firewall from HostA to HostB, but not from HostB to HostA, your rule base must include the following three rules:

Without the tsolpeerinfo rules, the telnet connection appears to connect and hang. Note that if your rules involve encryption, the tsolpeerinfo rules must be modified to include the relevant encryption parameters as well.

Alternatively, you could define a group--HostA+B--containing both hosts. Rules 2 and 3 could then be combined to form the following rule:


Caution - Caution -

The tsolpeerinfo service does not work with dynamic NAT. Assume a client goes through a firewall and its address is dynamically changed with NAT. The server tries to getpeerinfo to the NAT address. Since this is a new connection initiated from a server that is unassociated with any state engine, this connection is dropped. There is no way to "de-NAT" the connection.


See the Trusted Solaris installation instructions in SunScreen 3.2 Installation Guide for details about installing SunScreen on a system running Trusted Solaris.