Enhance SERVAUTH class to control use of Remote Execution (REXECD, RSHD, REXEC, RSH, orexecd, orshd, orexec, orsh) for PCI

This item is not in our plans but is being kept in our backlog.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS Communications Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Enterprise Networking
Product - z/OS Communications Server

This requirement will be accepted as an uncommitted candidate, but if it was implemented, the likely direction would be the broader implementation discussed in the above comment thread.

Joel, after our e-mail exchange and some internal discussions, I don't believe that what you've proposed is a complete solution.   The reason is that such a SERVAUTH resource would only protect the actual rsh, rexec, etc. executables that ship with Comm Server.   However, since the protocols for (as well as source code implementations of) these commands are publicly available, it would be a relatively small effort for a user to just implement their own version of any of these commands for use on z/OS.   Such implementations would completely bypass the SERVAUTH checks that would be built into the IBM-supplied commands.   

A more complete solution would be to put RACF controls on the ability for a z/OS userid to establish an outbound connection to a given remote port.  This could be done globally or it could be done so you could scope the controls to a specific set of remote IP addresses.  However, such a solution would again involve configuration beyond just RACF.   

Please let me know your reaction to  these observations and whether the more generalized solution is something you would be likely to use.

Joel responded to the above question via e-mail.  The following summarizes his answer:

For Joel's needs, using the PORTACCESS resource in the SERVAUTH class adds too much complexity because of health checking.  Specifically, Joel has to collect a significant amount of verification data on a somewhat regular basis for his PCI auditors.  Given the volume of information to be collected, he would prefer to have a single point of control for enforcement and reporting - he sees that single point of control as RACF.  If PORTACCESS is part of the solution, then he must also snapshot the TCPIP PROFILE and provide correlation information between the RACF ACLs and the related PORTACCESS statements in the profile.

Based on this, Joel would prefer a SERVAUTH profile that secures any use of RSH and REXEC for the client or daemon as well.

Have you looked at using the PORTACCESS resource in the SERVAUTH class to protect access to the server-side applications here?  That essentially controls which users can bind to the the listening socket for the given application.   Granted, that does not address the client-side apps, but please let me know if PORTACCESS meets your needs for the server-side applications.  If so, then we can narrow the scope of this requirement to rexec, rsh, orexec and orsh.