We are about to publish a security update that will affect all shops, but absent certain preventative action, will be disruptive to ACF2 shops.
All shops will see new messaging at the start of certain debugging sessions, but ACF2 shops will also see those sessions fail with s306-0C abends!
To avoid the abends, ACF2 shops will have to implement a new security rule prior to installing an upcoming maintenance update. (NOW would be a good time to do that.)
The rule we are creating will plug a serious omission in z/XDC's use of system security, so we really need to do this.
To avoid the failures (and to retain legacy behavior), ACF2 shops need to create a particular security rule ahead of time. The rule they will need to create is:
- UID(-) SERVICE(READ) ALLOW
This rule will be ignored until the update is applied. So right now would be a very good time to create this rule.
The update that we will publish is able to maintain legacy behavior in RACF and TSS shops, so applying the update will not be disruptive there. However, a fundamental characteristic of ACF2 makes it not possible to automagically retain the legacy behavior when that is the security system. Retaining the behavior will require you to create the above rule.
What Debugging Sessions are Affected?
The update affects debugging sessions started via the XDCCALLA (or XDCCMDA) utility.
The update also affects sessions started via the z/XDC Startup Panel in ISPF, but only when:
- Option 1 or 2 is selected. [Option 3 is not affected.]
- And the answer to the "Should CMD/PGM start APF auth?" question is yes.
- [Startup Panel users are affected because under the covers, options 1 and 2 (with auth=yes) invoke XDCCALLA and XDCCMDA, respectively, to start the debugging session.]
Debugging sessions started by hooks are not affected. Also unaffected are:
- Sessions started by XDCCALL and XDCCMD.
- Sessions started by direct calls out of user written ESTAE routines.
What the Update Does
For all security systems (RACF, TSS and ACF2), the update will allow a Security Office to control a decades old behavior that our customers find extremely useful, but has to be brought under a Security Officer's control due to the world's worsening security environment.
The security sensitive event occurs under the following circumstances:
- You intend to develop or debug an APF authorized program.
- The program is located in your private, non-APF development or testing library.
- You allocate that library either via ddname TASKLIB or via the Tasklib DSNs fields in the Startup Panel.
- You start your debugging session:
- Using XDCCALLA/CMDA
- Or using option 1 or 2 from the z/XDC Startup Panel with auth=yes specified.
Current Behavior: When XDC receives control APF authorized, it calls System Security to check the [XDC.]AUTH rule to see whether or not you have permission to use XDC in key0/supervisor state. If denied, the session aborts.
This has always been the case, and will remain the case going forward. There is no change regarding this security check.
Old Behavior: When XDCCALLA/CMDA received control, it opened the TASKLIB ddname and then checked to see if it was APF authorized. If not, then it changed a flag to temporarily make it APF authorized for the debugging session. (Its status outside of the debugging session remained unchanged.)
New Behavior: Previously, the only security control for this behavior was the above described [XDC.]AUTH check. This update adds an additional security control that is more specific to what is being done by XDCCALLA/CMDA.
So now, before up-levelling the TASKLIB, XDCCALLA/CMDA will make the additional security call, and either will or will not uplevel TASKLIB, according to security's ruling.
New Behavior: Also, this update adds new messaging both to ensure the user is aware of what XDCCALLA/CMDA is doing and to alert a Security Officer when the action being taken is something he might want to be aware of.
What Happens When the New Rules Do Not Yet Exist
Because it is likely that the new rules will not yet have been created when this update is applied, XDCCALLA/CMDA attempts to retain its legacy behavior. In RACF and TSS shops, this attempt succeeds. In ACF2 shops, it fails!
In RACF and TSS shops, when the new rules do not yet exist, the legacy behavior is retained, but the new messaging does occur. Specifically:
- TASKLIB's APF status is still up-levelled.
- But the Security Officer is alerted that this has happened.
- And messaging is also sent to the user so that he too knows that this has happened.
In ACF2 shops, absent the creation of new rules, the following will occur:
- The attempt to change TASKLIB's APF level is not made.
- The user receives messaging about this.
- Subsequently, the debugging session is likely to fail with an s306-0C abend.
In ACF2 shops, where the new rules have been created, the following will occur:
- TASKLIB's APF level either will or will not be changed according to the ruling.
- The user will receive appropriate messaging.
- If the ruling is to deny permission to uplevel the task library's APF state, it is likely the debugging session will fail with an s306-0C abend.
Details About the New Rule
Where librarynamemask identifies one or more libraries that the current user is (or is not) allowed to change from non-APF to APF.
XDCCALLA/CMDA will call System Security for each non-APF library in the task library concatenation.
To retain legacy behavior:
- RACF and TSS shops do not need to do anything. The absence of any applicable [XDC.]APF.librarynamemask rules will allow the legacy behavior to continue.
- ACF2 shops will need to create the following rule:
- UID(-) SERVICE(READ) ALLOW
This restores the legacy behavior of allowing any user (who is authorized to run z/XDC in key0/supervisor state) to uplevel any non-APF load library. [You may, of course, choose to start off with more refined rules for creating more precise controls.]
To create new controls over who may and may not uplevel which non-APF libraries, the Security Officer will have to create suitable [XDC.]APF.librarynamemask rules. For example, in ACF2, the following rules will give Ron and Dave differing permissions for what libraries they can and cannot uplevel:
DAVE.TEST.- UID(DAVE) SERVICE(READ) ALLOW
RON.- UID(RON) SERVICE(READ) ALLOW
- In ACF2, a "not protected" case would cause permission to be denied.
- In RACF and TSS, a "not protected" case would cause permission to be granted.
When Will the Update be Published?
The update has been written, but we are delaying publishing it to give ACF2 shops time to implement their new rules. At this point, we are expecting to publish in the last half of January 2024.
Suitable messaging will be added to our maintenance download page when the time comes.