SO_BROADCAST socket option

IPv4 IP addresses are divided into a network portion, an optional subnetwork portion, and a host portion. Normally, UDP and RAW datagrams are delivered to the single peer system identified by the destination IP address. However, when the destination address is a subnetwork or network base address (host portion is all zeros), or a subnetwork or network broadcast address (host portion is all ones), the datagram is delivered to every peer system in that subnetwork or network. Socket semantics require that an application set the SO_BROADCAST option on before attempting to send a datagram to a base or broadcast address. This protects the application from accidentally sending a datagram to many systems. Network access control does not check to see if there are other security zones defined within the scope of a destination subnetwork or network address or whether the user is permitted to send a datagram to all of these security zones.

Control over setting this socket option allows the system administrator to restrict use of subnetwork or network addresses to those users or programs that require them. This support is enforced at the PFS layer and applies to all z/OS® Communications Server socket APIs.

TCP/IP programs known to set the SO_BROADCAST socket option include:

OMPROUTE
sntpd, when invoked with the -b option

Additionally, any programs that use the clnt_broadcast() service in the SUN RPC libraries, or the send_pkt(sock, pkt, addr, broadcast) service in the NCS RPC library with the broadcast parameter set, require permission to the SO_BROADCAST socket option. The following TCP/IP programs use RPC services that require permission to broadcast:

rpcinfo, when invoked with the -b option
orpcinfo, when invoked with the -b option

The socket option to be protected is represented by the resource name EZB.SOCKOPT.sysname.tcpname.SO_BROADCAST. When this profile is defined, users of any program setting this option require READ permission. Access to the option is also allowed if the security server indicates there is no profile covering this resource. Conditional access lists, such as PERMIT WHEN(PROGRAM(...)), are supported for profiles covering socket option access control resources. There are no new TCP definitions required.

Guideline: Some security products do not distinguish between a resource profile that is not defined and a user that is not permitted to that resource profile. If your product does not make this distinction, you must define the socket option resource profile and permit users to it whenever the SERVAUTH class is active.

The following example shows the definitions:

RDEFINE SERVAUTH EZB.SOCKOPT.*.*.SO_BROADCAST UACC(NONE)
PERMIT EZB.SOCKOPT.*.*.SO_BROADCAST CLASS(SERVAUTH) ACCESS(READ) ID(OMPROUT)
PERMIT EZB.SOCKOPT.*.*.SO_BROADCAST CLASS(SERVAUTH) ACCESS(READ) ID(*) 
WHEN(PROGRAM(ORPCINFO))

The program name listed in the conditional access list must be the name the program is invoked by. Most TCP/IP applications are invoked by an alias name rather than the module name. Table 1 lists TCP/IP applications that send broadcast datagrams:

Table 1. TCP/IP application load module and alias names
Load module	Alias
EZAORRTE	OMPROUTE
EZASNTPD	SNTPD
EZARPCIN	RPCINFO
EZARORNP	ORPCINFO

Tip: In the UNIX System Services environment, both /bin/rpcinfo and /bin/orpcinfo are externally linked to ORPCINFO. Either command executes the EZARORNP program.

To use program names in conditional access lists, the program must be loaded into a controlled environment from a program controlled data set. TCP/IP applications are distributed in the SEZALOAD load library. To program control this data set, you must add it to the ** profile in the PROGRAM class as follows:

RALTER PROGRAM ** ADDMEMBER('TCPIP.SEZALOAD'//NOPADCHK)

For more information on program control, see z/OS Security Server RACF Security Administrator's Guide.