To
use xfwp there must be an X proxy manager running in the local environment
which has been configured at start-up to know the location of the xfwp.
[NOTE: There may be more than one xfwp running in a local environment;
see notes below on load balancing for further discussion.] Using the
xfindproxy utility (which relays its requests through the proxy manager)
a user asks xfwp to allocate a client listen port for a particular X server,
which is internally associated with all future connection requests for
that server. This client listen port address is returned by the proxy
manager through xfindproxy. The xfwp hostname and port number is then passed
out-of-band (i.e., via a Web browser) to some remote X client, which will
subsequently connect to xfwp instead of to the target X server.
When an X client connection request appears on one of xfwp's listen ports,
xfwp connects to the X server associated with this listen port and performs
authorization checks against the server as well as against its own configurable
access control list for requesting clients. If these checks fail, or if
the requested server does not support the X Security Extension, the client
connection is refused. Otherwise, the connection is accepted and all ensuing
data between client and server is relayed by xfwp until the client terminates
the connection or, in the case of an inactive client, until a configured
timeout period is exceeded. Xfwp is designed to block while waiting for
activity on its connections, thereby minimizing demand for system cycles.
If xfwp is run without a configuration file and thus no sitepolicy is defined, if xfwp is using an X server where xhost + has been run to turn off host-based authorization checks, when a client tries to connect to this X server via xfwp, the X server will deny the connection. If xfwp does not define a sitepolicy, host-based authorization must be turned on for clients to connect to an X server via the xfwp.
In order for xfwp to do its job, restrictions on access for ports 6001 - 6xxx must be removed from the rule-base of the IP packet-filtering router. [NOTE: xfwp only assigns ports in the range beginning with 6001; access to port 6000 on all Intranet hosts may continue to be denied.] This does not mean the Intranet firewall will be opened for indiscriminate entry by X clients. Instead, xfwp supports a fully configurable rule-based access control system, similar to that of the IP packet-filter router itself. Xfwp in effect adds another level of packet-filtering control which is fully configurable and applies specifically to X traffic. See section entitled CONFIGURATION FILE, below, for further details.
Each connection-type has a default number of allocation slots and a default timeout. The number of allocation slots for PM connections and X server connections is configurable via command line options. Connection timeouts are also configurable via command line options. Each connection timeout represents the period the connection will be allowed to remain open in the absence of any activity on that connection. Whenever there is activity on a connection, the time-to-close is automatically reset. The default distribution of total process connection slots across the four connection types, as well as the choice of default timeouts for the connection types, is governed by a number of assumptions embedded in the xfwp use model.
The default number of PM connections is 10 and the default duration for PM connections is 3,600 seconds (1 hour) for each connection after time of last activity. At start-up, xfwp listens for PM connection requests on any non-reserved port (default of 4444 if not specified on the xfwp command-line). The PM normally connects to xfwp only when a call is made to the PM with xfindproxy. Thereafter, the PM remains connected to xfwp, even after the messaging between them has been completed, for the default connection duration period. In some cases this may result in depletion of available PM connection slots. If the sysadmin expects connections to a single xfwp from many PM's, xfwp should be started using the -pdt command line option, with a timeout value reflecting the desired duration that inactive connections will be permitted to remain open.
Xfwp client listeners are set up by a call to xfindproxy and continue to listen for X client connection requests for a default duration of 86,400 seconds (24 hours) from the point of last activity. After this time they are automatically closed and their fd's recovered for future allocation. In addressing the question of how to choose some alternative timeout value which will guarantee the availability of client listen ports, sysadmins should take into consideration the expected delay between the time when the listener was allocated (using xfindproxy) and the time when a client actually attempts to connect to xfwp, as well the likelihood that client listeners will be re-used after the initial client data connection is closed.
Each client connection is allocated a default lifetime of 604,800 seconds (7 * 24 hours) from the point when it last saw activity. After this time it is automatically closed and its fd's recovered for future allocation. Because server connections are not actually established until a connection request from a remote X client arrives at one of the xfwp's client listen ports, the client data timeout applies both to client-xfwp connections as well as to xfwp-server connections. If the system administrator expects many client data connections through xfwp, an overriding of the default timeout should be considered.
If a line in the configuration file begins with the '#' character or a new-line character, the line is ignored and the evaluator will skip the line.
The configuration file supports two entirely independent authorization checks: one which is performed by xfwp itself, and a second which is the result of xfwp's querying the target X server. For the first of these, the configuration file employs a syntax and semantic similar to that of IP packet-filtering routers. It contains zero or more source-destination rules of the following form:
{permit | deny} <src> <src mask> [<dest> <dest mask> [<operator> <service>]]
For the second type of authorization check, the configuration file contains zero or more site policy rules of the following form:
{require | disallow} sitepolicy <site_policy>
The algorithm for rule-matching is as follows:
while (more entries to check)
{
if ((<originator IP> AND (NOT <src mask>)) == src)
[if ((<dest X server IP> AND (NOT <dest mask>)) == dest)]
[if (service fields present and matching)]
do either permit or deny connection depending on keyword
else
continue
}
if (no rule matches)
deny connection
If a permit or deny rule does not specify a service and operation, then the rule applies to all services. If a configuration file is specified and it contains at least one valid deny or permit rule, then a host that is not explicitly permitted will be denied a connection.
Site policy configuration checking constitutes a separate (and X server only) authorization check on incoming connection requests. Any number of require or disallow rules may be specified, but all rules must be of the same type; that is, a single rule file cannot have both ``require'' and ``disallow'' keywords. The algorithm for this check is as follows:
if (X server recognizes any of the site policy strings)
if (keyword == require)
permit connection
else
deny connection
else
if (keyword == require)
deny connection
else
permit connection
The site policy check is performed by xfwp only if the source-destination rules permit the connection.
EXAMPLES
# if and only if server supports one of these policies then authorize # connections, but still subject to applicable rule matches # require sitepolicy policy1 require sitepolicy policy2 # # deny pm connections originating on 8.7.6.5 [NOTE: If pm service # is explicitly qualified, line must include destination fields as # shown.] # deny 8.7.6.5 0.0.0.0 0.0.0.0 255.255.255.255 eq pm # # permit xfindproxy X server connects to anywhere [NOTE: If # fp service is explicitly qualified, line must include source fields # as shown.] # permit 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq fp # # permit all connection types originating from the 192.0.0.0 # IP domain only # permit 192.0.0.0 0.255.255.255
Care should be taken that source-destination rules are written in the correct order, as the first matching rule will be applied. In addition to parser syntax checking, a special command-line switch (-verify) has been provided to assist the sysadmin in determining which rule was actually matched.
Xfwp should check server site policy and security extension before allocating a listen port.