Diagnosing access control problems

This topic describes selected procedures for TCP/IP Services component trace, packet trace, and Socket API trace.

This topic contains the following sections:

Tip: The SAF interface allows security servers to return the following responses to access control questions:

Allow: User is permitted to resource with requested level of access.
Deny: User is not permitted to resource with requested level of access.
No decision: Class is not active or covering profile is not defined.

For many resources, TCP/IP allows access when a No decision is returned. RACF® supports the No decision response. Some security server products do not support the No decision response. They always return Deny when a resource has no profile. If you are using one of these other security servers, you must define profiles for these resources to allow any user to use them.

TCP/IP creates resource names in the SERVAUTH class to represent the services it protects.

These resource names are comprised of the following tokens:

The first token is always EZA or EZB.
The second token represents the type of services.
The third token is the eight-character MVS™ system image name.
The fourth token is often the TCP/IP job name.

Additional tokens can be defined for more granularity on certain types of services. For more information about services that TCP/IP protects and the resource names used, see the security topic in z/OS Communications Server: IP Configuration Guide.

You define RACF profiles in the SERVAUTH class to control access permissions to these resource names. A discrete profile has the same name as a resource and covers only that resource. A generic profile uses wildcard symbols to cover many resource names. The SERVAUTH class is a general resource class, so you use the RACF RDEFINE, RLIST, RALTER, RDELETE and PERMIT commands to manage these profiles. For more information, see z/OS Security Server RACF Security Administrator's Guide and z/OS Security Server RACF Command Language Reference.

Except for a few documented cases, TCP/IP checks for READ access to resources. Users might be given access to a resource in several ways. A RACF profile defines universal access (UACC) that provides the default level of access for all users not explicitly named. Individual users and user groups might be given a different level of access, higher or lower, with the PERMIT command. Use the WHEN clause to define conditions that must be met before the specified access is granted.

Tip: The RACF WHEN(PROGRAM(...)) clause has restrictions on profiles in the SERVAUTH class. It can be ignored on some resource checks and should only be used for resource names that explicitly document support.

RACF can be configured to write audit messages to the console. The default for profiles in the SERVAUTH class is to write a message when access is denied. These messages indicate the user, resource name, profile name and access level requested. When you first put an access control policy in place, you might want to configure the profile to produce audit messages on successes as well. You might also want to configure the profile with the WARNING parameter. This causes RACF to write the audit failure messages and then return allow to the resource manager. This allows you to test the effectiveness of a proposed policy without impacting usage.

Tips:

Some policy changes do not take effect until the next time a user logs on or starts a job. After changing the policy, the user might need to log off or a job might need to be canceled and restarted.
TCP/IP caches results when it checks access to NETACCESS resources. This cache is purged when a NETACCESS statement is found in a file used with the VARY TCPIP,,OBEYFILE command. It is also purged when an ENF signal is received from RACF indicating that the SERVAUTH class or SECLABEL class has been refreshed. If your security server does not produce this ENF signal then, after making policy changes, you must issue the VARY TCPIP,,OBEYFILE command with a file containing the NETACCESS statement to cause TCP/IP to purge cached responses.

Several of the TCP/IP services that provide access control check socket calls made through several different interfaces. When access to a resource is denied, the errno returned is EACCES. The errno2 field provides additional information about the failure. Programs that provide diagnostic logs should include the errno2 field. For information about the contents of the value returned, see z/OS UNIX System Services Programming: Assembler Callable Services Reference.

Tip: Many C programs use the perror() or strerror() library service to display errors encountered. There is an environment variable _EDC_ADD_ERRNO2, which when set to 1, appends the current errno2 value to the end of the perror() string as shown below:

 EDC5121I Invalid argument. (errno2=0x0C0F8402)

TCP/IP access control failures are recorded in the event trace (SYSTCPIP) for TCP/IP stacks with the ACCESS option.