As there is no target security authorization checking done yet for cross-system MSF actions in OPS/MVS, we have protected our production systems from unauthorized actions from test systems by defining the MSF links to test systems as NOSECURE in our production systems.
So, on PROD system, the MSF link to test system is defined as NOSECURE.
But, we noticed that via OPS;1, we are still able to issue non-display commands (modify, stop, cancel, ...) from a test lpar on a PROD system.
We would have expected that only DISPLAY commands would be seen as READ and therefore be granted by the NOSECURE implementation, but that non-display commands are seen as an UPDATE action and therefore wouldn't be granted due to the NOSECURE implementation...
OPS/MVS
OPSRMT and OPSCMD can issue commands whose authority level checking is bypassed. When OPSRMT or OPSCMD
issues a cross-system command, the command eventually executes on the remote system using the authority levels
assigned to the OPS/MVS address space.
This same problem can arise when OPSRMT or OPSCMD is invoked with the name of the local system. The command
executes in the OPS/MVS address space of the local system and will be checked by your security system against the
authority level of the OPS/MVS address space.
Other non-system commands can be secured by noting on a receiving (LOCAL) LPAR that the commands from a given remote LPAR are considered not to be secured via the NOSECURE parameter. In this instance only display and query commands will be accepted by the LOCAL system. SECURE remote systems can send both query- and update-type operations to this system. Systems
that are defined as NOSECURE systems can only send display- or query-type operations to this system
It needs to be noted that the NOSECURE definition applies only to OPS/MVS provided commands, environments, and OPS/REXX functions. It will not apply to non-OPS/MVS commands like MVS, JES, or other products.