|
|
|
Another potential security problem involves a subsystem’s ability to bypass data set access validation by some access control software packages. Some access control software does not validate data set access for subsystems defined at IPL. If it did, and if access permissions that were erroneously specified prevented the primary job entry subsystem from operating, the user would be stuck. The user could not fix the access permission without bringing up the primary job entry subsystem, but he could not bring up the primary job entry subsystem without correcting the access permissions.
If a subsystem is initialized at IPL by specifying a subsystem initialization routine in IEFSSNxx, it can be active without having a started task associated with it. This can also happen if a subsystem terminates without doing the proper cleanup. Either way, the subsystem can be active without showing up on a display of active jobs. In this way, it can silently alter the operator command stream while leaving no audit trail. The Subsystem Display (3.1) helps you determine when a subsystem was initialized. If it lists a subsystem as defined in IEFSSNxx or dynamically, you can use the Parmlib IPL Map Display (2.1.1) to determine if the subsystem was defined in an IEFSSNxx member. If it was not, then it was defined dynamically.
CA Auditor shows you the name of each subsystem defined to the system. This name does not have to match any job name in the system. The Subsystem Display (3.1) can also show “nondisplayable” subsystem names in a hexadecimal format. One of the following classifications is given for each subsystem:
You should discuss each user‑defined subsystem with the technical support staff to determine its function.
| Copyright © 2009 CA. All rights reserved. | Tell Technical Publications how we can improve this information |