The System Authorization Facility (SAF) in a network context

What exactly can SAF do in a networking context? It can collectively do more to restrict end-user capabilities than any organization might ever want to implement. In other words, the security features listed here might be used in combinations, but it is unlikely that any organization would want to implement more than a few of these features.

Every organization is unique. Most organizations will find that some of the SAF-based security features listed here have a place in the context of their security policy.

Stack access

A single LPAR can contain more than one active TCP/IP stack. And for the most part, if the application has been coded to support it, a stack can be accessed by changing the TCPIPJOBNAME statement in a resolver configuration file. That sounds like a security exposure, and it is. SAF can be used to restrict which TCP/IP stack can be accessed by any individual user ID.

Network access

One of the standard methods of penetrating a network is to use intermediate hosts as access points. An organization might want to limit such a possibility. In addition, some user IDs on the z/OS host might be used by either less experienced or less trusted users. Using SAF, entire networks or subnetworks can be restricted on an individual user ID basis.

Port access

In order for a hacker to continue through an intermediate host, a port is required. SAF can be used to restrict the range of ports that a user ID can access. In addition, port access can be used to add extra security to the user IDs associated with a server or daemon. Since some servers may run with z/OS UNIX superuser authority, port access can be used to restrict a user ID to only using the port number(s) it requires.

Note: In a UNIX context, superuser authority or root authority refers to any user ID with a UID of 0. A user ID with a UID of 0 has near complete control over the UNIX operating environment.

On a z/OS host, this is not quite as dangerous as on a pure UNIX-like operating system--but superuser authority still has very serious implications and must be regulated accordingly.

Netstat command

The output from the netstat command, depending upon the option used, can be considered a security risk. For example, information about attached networks or interface type could be used to the advantage of a hacker. Using SAF, all or some of the netstat command options can be restricted.

Reminder: The netstat command on z/OS is available from within a z/OS UNIX or TSO environment. The z/OS netstat command is implemented in the same fashion as the netstat command that is found on Windows and UNIX style operating systems. It can be used to display session and network status of the IP network.

Packet tracing

TCP/IP on z/OS supports a packet tracing service. The service uses a facility of the MVS operating system itself (called CTRACE) to perform low-impact packet tracing, including filtering options. There is a z/OS packet trace formatting environment, but the data can also be exported in formats compatible with workstation trace analysis tools. Packet tracing should be controlled to prevent unauthorized tracing of data.

So, how does all this SAF control get put into place? Within the SAF environment is a class of resources called SERVAUTH. The SERVAUTH class can have resources defined to represent IP features.

Using the same order as above, the resource definitions begin with something that looks like the following:

EZB.STACKACCESS....
EZB.NETACCESS....
EZB.PORTACCESSS....
EZB.NETSTAT....
EZB.NETMGMT....

After such a resource has been defined, a universal access permission must be set. For example, a universal access of none might be used. This would implicitly protect the resource from being used by any users. Individual user IDs (or groups of user IDs) could then be given access to the resources as needed.