Using the PORT statement to control access to all unreserved ports

In addition to reserving particular ports, you can also use the PORT statement to control application access to user-specified ports that have not been reserved. Access control is applied when an application issues an explicit bind or a TCP listen.

You can use job names or SAF resources, or a combination of both, to control access to user-specified unreserved ports, or you can unconditionally deny access to user-specified unreserved ports. You do this by configuring one or more PORT statements in which the port number is replaced by the keyword UNRSV.

Result: PORT UNRSV statements control access to nonzero, unreserved ports specified on explicit binds. Access to unreserved ports that are assigned by the stack is not affected.

If you want to use PORT UNRSV access control, see the following considerations:

Using the parameters on the PORT UNRSV statement
To use only job names to control unreserved port access, configure one or more PORT UNRSV statements using the JOBNAME keyword with specific job names or partial wildcard job names (1 - 7 characters, followed by *). If you specify the wildcard job name (*), the PORT UNRSV statement applies to all job names. If an application's job name matches more than one PORT UNRSV statement, the statement with the closest matching specified job name is used to control access to unreserved ports.

To use a SAF resource instead of job names to control unreserved port access, configure a PORT UNRSV statement specifying the wildcard job name (*) and the SAF keyword and resource name. Because you can have only one PORT UNRSV statement with the wildcard job name per protocol, this method allows the use of only one SAF resource per protocol.

To use a combination of job names and a SAF resource to control access, specify the SAF keyword and resource name on one or more PORT UNRSV statements with different job names. You can specify a different SAF resource on each of these PORT UNRSV statements.

If you do not configure any PORT UNRSV statements for a protocol, all applications are allowed to use unreserved ports. This is the default behavior. To change this behavior and unconditionally deny access to user-specified unreserved ports, configure a PORT UNRSV statement, specifying the wildcard job name (*) and the keyword DENY.

For the UDP protocol, access is always controlled when an explicit bind is issued (WHENBIND). For UDP applications, there is no distinction between client or server roles because there is no explicit socket API that indicates that the application is a UDP server. All UDP applications that bind their socket to a specific local unreserved port do need to pass any configured UDP port access control checks.

For the TCP protocol, you can control access to user-specified unreserved ports when the explicit bind is issued (WHENBIND) or when a listen is issued on that port (WHENLISTEN). WHENLISTEN access control is targeted to TCP applications acting as servers (that is, applications able to accept incoming client TCP connections) and is the default for TCP. If the default is used or WHENLISTEN is specified, and no listen is issued for the unreserved port, no access control check is made. WHENBIND access control can affect TCP client applications that bind to a specific local port for outbound TCP connections. Every PORT UNRSV statement for the TCP protocol must specify the same access control. You cannot specify WHENLISTEN on some statements and WHENBIND on other statements. If you do, the conflicting configuration statement will fail.
Implementing PORT UNRSV access control in stages
Using PORT UNRSV access control can have unexpected consequences. Consider implementing this function in the following stages:
1. Determine the necessary port reservations statements for your applications.
  For example, you might begin with 'PORT UNRSV TCP * SAF xyz WHENBIND', where the SERVAUTH profile has UACC(READ) and auditing of successes is enabled. This would give you an indication of how many applications currently bind to unreserved ports. Verify the applications reported, and if deemed valid, reserve their ports using the PORT or PORTRANGE statements.
2. Enable access control enforcement by specifying DENY or a SAF resource with UACC(NONE) and monitor failures.
  As failures are identified, configure appropriate PORT reservation statements to allow authorized application access to those ports.
Enforcing PORT UNRSV access control
If you configure one or more PORT UNRSV statements for a protocol, access is unconditionally denied to any application that explicitly binds to an unreserved port and does not match the protocol and job name on any of the configured PORT UNRSV statements. Applications that explicitly bind to an unreserved port and that do match the protocol and job name on a PORT UNRSV statement are allowed to access the unreserved port, unless the access is restricted by the SAF or DENY keywords. If the SAF keyword is specified, the user ID associated with the application that attempts to access the port must be permitted to the specified SAF resource. If the DENY keyword is specified, access is unconditionally denied.
Rules: If you configure PORT UNRSV statements for UDP or for TCP with the WHENBIND option, the following rules apply:
- Every application using that protocol that explicitly binds to a user-specified local unreserved port is subject to an authorization check. If the application does not have authority to access an unreserved port, the bind will fail.
- For TCP, every client connection that first performs an explicit bind and explicitly specifies a local unreserved port is subject to an authorization check for access to unreserved ports.
- Because client programs might run under many different user IDs, all address spaces in which the client program can run must be authorized (by job name, SAF resource, or both) to access an unreserved port.
  Alternatively, you can use the WHEN(PROGRAM) type of RDEFINE statements to authorize specific programs to a particular port, regardless of the address space in which they run. However, in this case these programs must be program-controlled resources.
If you do not configure a PORT UNRSV statement for a protocol, then access to unreserved ports using that protocol is not controlled. If you do configure PORT UNRSV statements for a protocol, access is determined by the PORT UNRSV statement with the job name that most closely matches the application's job name; if the applications's job name does not match any of the PORT UNRSV statements, then access to unreserved ports is denied for that protocol.