Network access control gives system administrators the ability to assign permission for z/OS® users to access certain networks and hosts. With this function, the ability of users to send or receive data between z/OS and certain networks can be controlled through z/OS. Network access control provides an additional layer of security to any authentication and authorization security that is used in the network or at the peer system by disallowing the unauthorized user to communicate with the peer network resource.
- The IP network is considered the resource to be protected.
- Use of the IBM® zEnterprise® System (zEnterprise) intranode management network is protected by OSM access control and is exempt from network access control. For more information, see OSM access control.
- IP addresses are classified into security zones, in which each zone has a certain level of security sensitivity. A default security zone exists for interfaces that are not explicitly associated with a specific security zone. Security zones consist of one or more, perhaps discontiguous, IP address ranges that have the same security sensitivity and are identified by a specific zone name.
- SAF is used to check whether users or groups of users have READ access to a security zone.
- You define a SAF resource profile for each security zone and provide READ access to these resources to the users or groups of users that you want to have access to particular security zones. A security zone is represented by the EZB.NETACCESS.sysname.tcpname.zonename resource name in the SERVAUTH class.
- TCP/IP keeps a mapping of network resources by IP address to security zones. This mapping is consulted on certain inbound and outbound operations to determine the corresponding resource zone name for the most specific network defined. Then the current user's access to that resource is queried using SAF, and the operation is allowed or denied completion accordingly. This mapping is also consulted when the security ioctl is issued to extract the port of entry zone name of a socket's current peer.
- Network access control is used to control z/OS user access to a peer address in an IP network through a sockets application. Resource access checks occur at connection setup or acceptance time for TCP, peer identification time for UDP and RAW, and on the first and potentially subsequent sends or receives (TCP, UDP, or RAW) to a particular destination in a socket's lifetime.
- Network access control is used to control z/OS user access to local addresses when a socket is bound to a local address. Resource access checks occur when an application explicitly binds a socket to a local address, including the IPv4 address INADDR_ANY (0.0.0.0/32) or the IPv6 unspecified address, in6addr_any (::/128). Job-specific or destination-specific source IP addresses (designated by the SRCIP profile statement) are handled as if the application did an explicit bind to the configured address.
- Network access control security checks are made at the transport layer (TCP, UDP, and RAW). Other IP-specific packets generated by the stack are not covered under this function (such as ICMP echo replies, for example). Additionally, there is no user concept when dealing with packets that are being forwarded through the stack, and hence no checks are made.
- Network access control for outbound and inbound can be individually enabled or disabled.
- TCP/IP caches security information following network access control
checks. Access is automatically rechecked on the next use of the cache
whenever the RACF® commands
SETROPTS RACLIST, SETROPTS RACLIST REFRESH, or SETROPTS NORACLIST
are issued for the SERVAUTH class. If you are using a security product
other than RACF, the NetAccess
zone table in the TCP/IP profile must be rebuilt to cause TCP/IP to
recognize changes to the SERVAUTH class profiles for existing sockets.
You can control the level of caching that is performed by using the CACHEALL, CACHEPERMIT, or CACHESAME parameter on the NETACCESS configuration statement in the TCP/IP profile. These parameters determine which network access control checks are resolved using the cache, without making a new call to SAF, and thus determine which checks can be audited by the security server product. For more information about these parameters and the NETACCESS statement, see z/OS Communications Server: IP Configuration Reference.
- The socket calls bind, connect, and those that send data will fail with errno EACCES if the specified IP address is not permitted to be used by the application user. Inbound UDP and RAW datagrams that are not permitted under the current network access control policy are normally filtered out before they get to socket calls that receive data. It is possible for a datagram to arrive under a network access control policy that would allow it to be read, but then be received after a policy change that does not allow it. If the application (or common INET) has issued a select or poll on the socket, the receive call returns an EACCES errno to avoid blocking the application. Inbound TCP connections that are not permitted under the current network access control policy are also normally reset and discarded before they get to the socket backlog. In those cases where the only available new connections are not allowed and a select has been issued, accept processing returns a new socket and the next attempt to send or receive data returns an ECONNRESET error.
- NetAccess inbound filtering needs to predict whether a future receive or accept will succeed. When there are multiple processes or threads operating on the same socket, to achieve consistent results you must ensure that certain calls are done under the same identity, or identities with equivalent network access control policies. For UDP and RAW sockets, the select, receive, and send calls must be done under equivalent policies. For TCP listening sockets, the select and accept calls must be done under equivalent policies.
Figure 1 provides an overview of network access control. z/OS user Bob is permitted access to Security Zone A but not Security Zone B. An outbound connect from Bob is permitted to Security Zone A, but not Security Zone B. Bob is permitted to accept connections from Security Zone A but not Security Zone B.
